[cdt-debug-dev] Debugging outside CDT project

[Øyvind Harboe <oyvind.harboe@xxxxxxxxx>]

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

Note that there are two issues here:

1. CDT not dealing with GDB being temporarily deeply unhappy about the
current stackframes giving weird responses. In this state GDB will come
out of "hyperspace" as soon as manual "step" + "stepi"'s are issued in
the GDB console. There are PR's open for this case for e.g. the ARM CPU.

2. GDB going ga-ga over a stackframe, literally looping forever,
SEGFAULT'ing etc.


I don't believe there is anything CDT should, or could, do about #2.



-- 
Øyvind Harboe
http://www.zylin.com