[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-debug-dev] Debugging outside CDT project
|
Yes, these are issues that we run into as well.
The way we've had to deal with it in our products is with GDB hackery to supply a single dummy stack frame when GDB knows you are not somewhere that corresponds to a function with symbol information. Otherwise you can get some nasty behaviour with GDB looping forever trying to traverse an infinite stack full of garbage. It's still not perfect however.
I am not sure what the answer is (if there is one) from the CDT side of things however. If GDB goes off into the weeds, there's not a whole lot you can do about it.
I wonder if it's possible to query GDB for the PC, and then use either GDB or the binary parser to figure out if that address lives somewhere that has symbol info. If the location doesn't have symbol info, do not request the stack.
___________________________________________
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
> -----Original Message-----
> From: cdt-debug-dev-admin@xxxxxxxxxxx [mailto:cdt-debug-dev-
> admin@xxxxxxxxxxx] On Behalf Of Øyvind Harboe
> Sent: Friday, December 03, 2004 8:19 AM
> To: cdt-debug-dev@xxxxxxxxxxx
> Subject: [cdt-debug-dev] Debugging outside CDT project
>
> One of the things that have improved tremendously lately is debugging
> code outside a CDT project(both with and without source code).
>
> To have first class support for debugging code outside CDT projects is a
> crucial part of supporting embedded debugging.
>
> When suspending a target with a hardware debugger(e.g. JTAG debugger),
> the CPU is suspended on the very next instruction, which could be
> anywhere, and oftentimes is inside an interrupt, exception handler etc.
>
> At this point disassembly/single-stepping is crucial.
>
> E.g. to establish where the interrupt came from, it is often necessary
> to single step a bit further to get enough context information. If there
> is any source code for the interrupt handler, it may very well be
> outside the CDT project.
>
> Obviously the application stack frame concept breaks down when stepping
> into and out of interrupts/exceptions/thread switches, etc., so it is
> important that CDT deals gracefully with weird stack frame replies from
> GDB.
>
>
> --
> Øyvind Harboe
> http://www.zylin.com
>
>
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
