Re: [RFC] Infinite backtraces...

[Randolph Chung <randolph@tausq.org>]

> I am sort of walking on thin ice here, though. I could very well
> imagine a case where we would rely on register value in one case,
> and a flag from whatever frame information we find in another case.
> This is why I'm mentioning this idea here. JIC.

yeah, relying on return pointer register values seems a bit iffy. I
suspect it might be zero in your case only by luck. on hppa-linux, for
example:

(gdb) bt
#0  thread_function (arg=0x0)
    at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.threads/manythreads.c:32
#1  0x405ee4b8 in pthread_start_thread () from /lib/libpthread.so.0
#2  0x405ee540 in pthread_start_thread_event () from /lib/libpthread.so.0
#3  0x40878514 in clone () from /lib/libc.so.6
#4  0x40878514 in clone () from /lib/libc.so.6
Previous frame identical to this frame (corrupt stack?)

so it terminates only because we are lucky... :(

for hppa-linux, i believe the correct fix is to fix glibc so that the
clone() procedure sets the "can't unwind" flag in the unwind record and
then using a mechanism similar to what you proposed, we can stop the
backtrace. 

in your particular case, i'm curious to know how we get from a pc=0
frame to a previous frame. that seems like a bug to me?

i like the idea of a new method. perhaps the default implementation
could be instead the "main" and "entry point" logic that's currently in
the core frame code, and targets can overload and enhance this method
accordingly?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/