[RFC] Infinite backtraces...
Andrew Cagney
cagney@gnu.org
Fri Dec 3 18:28:00 GMT 2004
Joel Brobecker wrote:
> Hello,
>
> I have been studying the few examples I have here where GDB creates
> an endless backtrace when we do a "bt". There is also the case that
> Randolph exposed, but I think his case was a bit particular.
>
> Still staying on hppa, I have the following example (code copied at
> the end of this message). What the code does is create one task that
> will call a null procedure Break_Me. We put the breakpoint on that
> procedure, and run until we hit that breakpoint, and then do a backtrace.
> Because we're inside a task, the call stack does not start at the entry
> point nor does it contain a call to the "main" procedure.
FYI,
I've a finish up a patch that checks for this:
> #6 0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
> #7 0x00000000 in ?? ()
I.e., a zero pc unwound from a normal frame. It is ``tricky'' to test
though :-(
The other thing that would help here is for glibc's CFI to identify the
return-address (and CFA) column as unknown (assuming I've got my CFI
term correct) on the outer most frame. It would then be easy for
dwarf2-unwind to identify this. It's been discussed, agreed, but not
implemented.
> I am not sure I have a sufficiently high-level view of the entire
> code that is involved in unwinding, but it seemed to me that we need
> to add a new architecture-dependent hook that would tell whether a
> given frame is the initial one, and that unwinding can not be done
> past this frame. This naturally pointed to a new gdbarch method.
>
> Something like gdbarch_upper_most_frame_p (....), with a default
> value that would always return false.
>
> And then, in get_prev_frame_1, either right after we check for
> this_frame->prev_p, or slightly after we get the ID of this_frame,
> we can add a call to this new method.
>
> I am still doing some researching about this, but I think that on
> hppa, the RP will always be initialized to 0 in the upper most frame.
> So we can stop the unwinding using that condition.
Right, but it shouldn't need an additional method. The per-architecture
unwinder, when it detects a frame that the ABI specifies as final,
should return a null frame ID. For instance, the PPC ABI explicitly
specifies that it's stack be terminated with a zero SP.
Finally, a more long term suggestion is that we add a mechanism for
creating or adding attributes to symbols (for instance for signal
trampolines). An atribute of such a symbol could be that it is outermost.
Want to help fill these gaps?
Andrew
More information about the Gdb-patches
mailing list