Better crash handling in gdb, was: Re: [Zephyr-devel] __ASSERT - transfer to error handler
I appreciate the response.
On Fri, 9 Nov 2018 17:57:03 +0000
"Boie, Andrew P" <firstname.lastname@example.org> wrote:
Yes, and actually, over the couple of years, I found that informationI'm patiently waiting for a paradise times when on CPU exception,We do dump this info to the console on a fatal CPU exception. On x86
to become more usable. Like, I remember when I just started with
Zephyr, I regularly hit cases when I couldn't get anything useful from
such a crash dump, while recently I noticed to myself that it was
helpful each time. I don't know whether format of it changed to be more
detailed/clear, or I got more experience with it, I assume both it.
But sure, it's still pretty far in usability from "desktop" debugging.
But it would be nice, if runningWell, if I knew how to do it, I'd go trying to do it myself ;-). So
far, I don't even understand how generic GDB stub (as run on real hw
for GDB debugging), qemu's "meta level stub", Zephyr's builtin stub
(which was remove some time ago) should/would interact to make it
possible to achieve that effect. I remember a year or so ago I set up
to read thru google results on "qemu gdb debugging support", but
figured it's too far-fetched from the normal "Zephyr development" of
which we have a lot to do in queue yet.
That said, you nailed it right - the "user feature request" is exactly
to be able to use GDB as used in normal workstation environment, where
if a binary segfaults, I can run it under qemu, and it's stop and allow
me to review the state right at the instruction which crashes.
So again, I appreciate the response here, let's keep at the back of out
minds, maybe we'll get to implement it later.
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog