Re: [RFC] Infinite backtraces...

[Joel Brobecker <brobecker at adacore dot com>]

> > I haven't run this through the debugger to confirm it, but it looks
> > like we used to stop the unwinding by using the name of the symbol
> > associated to the frame. Not very elegant, to say the least, but
> > could be effective for hpux (it would no longer be just architecture
> > dependent).
> 
> erk, yuck :)

:-)

> yeah, but i would have expected that you should get an error when 
> unwinding from 0 ("Cannot find bounds of current function ..."). this
> should automatically stop the backtrace.
> 
> would you mind sending me the output of "info reg" frame frame 5 and 6,
> "maint print unwind __pthread_create_system" and "disassemble
> __pthread_create_system"?

Sure. The regs information is attached.

(gdb) maint print unwind __pthread_create_system
unwind_table_entry (0x401d0624):
        region_start = 0x7aee0b40 <__pthread_create_system>
        region_end = 0x7aee0c3c <__pthread_create_system+252>
        flags = Args_stored Save_RP
        Region_description = 0x0
        Entry_FR = 0x0
        Entry_GR = 0x5
        Total_frame_size = 0x18

I also attached the assembly listing.

> yes and no.... i don't know all the history, but i believe the new frame
> code in gdb 6.x is more explicit about unwinding through various frames,
> including stub frames. on hpux export stubs show up in backtraces
> because they occupy stack space. (hppa-linux doesn't use export stubs).
> i don't like it either, but not sure what we can do about it.

I'll give it a try and see if we can skip them. I like the idea of
having a switch to hide them, though. That would be very nice. but
then we need to add a new type of frames. As far as I can tell
(understand: from code inspection), the stub frames are marked as
NORMAL_FRAMEs.

> see:
> http://sources.redhat.com/ml/gdb-patches/2004-05/msg00741.html

Thanks muchly for the pointer. I missed that thread.

> another possibility is that you found a bug; we still have lots of
> bugs on hpux :(

Probably not this time :-).

-- 
Joel

Attachment: frame5.txt
Description: Text document

Attachment: frame6.txt
Description: Text document

Attachment: disass.txt
Description: Text document