Hello Andrew,


I appreciate the response.

On Fri, 9 Nov 2018 17:57:03 +0000
"Boie, Andrew P" <andrew.p.boie@...> wrote:

I'm patiently waiting for a paradise times when on CPU exception,
assert, etc., we'll be ending up in debugger, point to the
instruction where the problem happened (or it can be seen in
backtrace).

We do dump this info to the console on a fatal CPU exception. On x86
there's even a crude stack trace.

Yes, and actually, over the couple of years, I found that information
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 running
some application under GDB, for the exception to simply break the
debugger at the offending instruction rather than go through Zephyr's
exception handling path.

I'm not sure how this could work, perhaps have the Zephyr exception
handler set up the stack/registers to the original context and issue
a debug exception? Or would this involve some kind of Zephyr-aware
extension to GDB? The problem is always that the stack layout for a
CPU exception is different than a function call, and might not even
be on the same stack, so you can't easily unwind through when the
exception happened to the original faulting context.

Well, 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.

Andrew

--
Best Regards,
Paul

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