Re: [RFC] Infinite backtraces...

[Andrew Cagney <cagney@gnu.org>]

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