[RFC] Infinite backtraces...

[RFC] Infinite backtraces...

[Joel Brobecker]

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.

The current output is an endless callstack:

    (gdb) b break_me
    Breakpoint 1 at 0xa32c: file simple.adb, line 27.
    (gdb) run
    Starting program: /[...]/simple 
    [New thread 2 (system thread 25946)]
    [Switching to thread 2 (system thread 25946)]
    
    Breakpoint 1, simple.break_me () at simple.adb:27
    27         end Break_Me;
    (gdb) bt 20
    #0  simple.break_me () at simple.adb:27
    #1  0x0000a2cc in simple.caller (<_task>=0x4001c3a0) at simple.adb:21
    #2  0x0000a268 in simple__callerB___2 () at simple.adb:18
    #3  0x00017184 in system.tasking.stages.task_wrapper ()
    #4  0x00017058 in system__tasking__stages__task_wrapper ()
    #5  0x7aee0f60 in __pthread_create_system () from /usr/lib/libpthread.1
    #6  0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
    #7  0x00000000 in ?? ()
    #8  0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
    #9  0x00000000 in ?? ()
    #10 0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
    #11 0x00000000 in ?? ()
    #12 0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
    #13 0x00000000 in ?? ()
    #14 0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
    #15 0x00000000 in ?? ()
    #16 0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
    #17 0x00000000 in ?? ()
    #18 0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
    #19 0x00000000 in ?? ()
    (More stack frames follow...)

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.

What do you think?

Thanks,
-- 
Joel

procedure Simple is

   -------------------
   -- Declaractions --
   -------------------

   task type Caller is
   end Caller;
   type Caller_Ptr is access Caller;

   procedure Break_Me;

   My_Caller : Caller_Ptr;

   ------------
   -- Bodies --
   ------------

   task body Caller is
   begin
      Break_Me;
   end Caller;

   procedure Break_Me is
   begin
      null;
   end Break_Me;

begin
   My_Caller := new Caller;
end Simple;

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

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

Something I forgot to add was that I thought about adding a frame
method (in the frame_unwind struct). But I don't this this is the
best approach, as you can have several unwinders active at the same
time for the same target, while the end-of-callstack condition
would remain the same reguardless of the type of unwinding we're
doing.

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.

-- 
Joel

Re: [RFC] Infinite backtraces...

[Randolph Chung]

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

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

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

So far, I haven't been able to find any documentation that would
guaranty that, indeed. So it's definitely iffy.

While working on something else, I just stumbled on this (in gdb 5.3):

  /* If this is a threaded application, and we see the
     routine "__pthread_exit", treat it as the stack root
     for this thread. */

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

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

It's funny that we share the same definition of being "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. 

Yes, if you can get that, I think that's by far the best approach.
Let the unwind information tell you instead of guessing.

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

Not sure. I haven't really looked at this in details, since this part
of the callstack was bogus anyway. But my guess is that the fallback
unwinder kicked in (since we shouldn't find any unwind entry for that
PC), and just unwound blindly.

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

I would prefer that the new method by called in addition to the current
logic. The reason being that, for architectures overriding the default,
they would have to reimplement that part again in addition of doing their
own magic.

BTW: You backtrace reminds me of something curious: 

> #3  0x40878514 in clone () from /lib/libc.so.6
> #4  0x40878514 in clone () from /lib/libc.so.6

I just noticed that I get a lot of duplicated frames in our backtraces.
Another example is the callstack I posted earlier:

    #1  0x0000a2cc in simple.caller (<_task>=0x4001c3a0) at simple.adb:21
    #2  0x0000a268 in simple__callerB___2 () at simple.adb:18
    #3  0x00017184 in system.tasking.stages.task_wrapper ()
    #4  0x00017058 in system__tasking__stages__task_wrapper ()
    #5  0x7aee0f60 in __pthread_create_system () from /usr/lib/libpthread.1
    #6  0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1

Frame #2 is a duplicate of #1, although it's hard to see if you don't
know the GNAT encoding. Same for frame #4 being a duplicate of #3.
Same for #5 and #6.

These frames are referring to stubs. With 5.3, we skipped these stubs.
Do you know if putting them here was intentional? I find them confusing,
so I'd like to remove them.

-- 
Joel

Re: [RFC] Infinite backtraces...

[Randolph Chung]

> While working on something else, I just stumbled on this (in gdb 5.3):
> 
>   /* If this is a threaded application, and we see the
>      routine "__pthread_exit", treat it as the stack root
>      for this thread. */
> 
> 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 :)

> > 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?
> 
> Not sure. I haven't really looked at this in details, since this part
> of the callstack was bogus anyway. But my guess is that the fallback
> unwinder kicked in (since we shouldn't find any unwind entry for that
> PC), and just unwound blindly.

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"?

> I would prefer that the new method by called in addition to the current
> logic. The reason being that, for architectures overriding the default,
> they would have to reimplement that part again in addition of doing their
> own magic.

well, they can call the default handler afterwards. but anyway, this is
just a minor detail.

> Frame #2 is a duplicate of #1, although it's hard to see if you don't
> know the GNAT encoding. Same for frame #4 being a duplicate of #3.
> Same for #5 and #6.
> 
> These frames are referring to stubs. With 5.3, we skipped these stubs.
> Do you know if putting them here was intentional? I find them confusing,
> so I'd like to remove them.

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.

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

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

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

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

> > 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 #2: frame5.txt --]
[-- Type: text/plain, Size: 2283 bytes --]

flags          0x29000041       687865921
r1             0x7aece150       2062344528
rp             0x1705b  94299
r3             0x4001f3b0       1073869744
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x7aece110       2062344464
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
r16            0x0      0
r17            0x0      0
r18            0x0      0
r19            0x0      0
r20            0xf      15
r21            0x0      0
r22            0x0      0
r23            0x0      0
r24            0x1      1
r25            0x4001b4c0       1073853632
r26            0x4001c3b8       1073857464
dp             0x40010998       1073809816
ret0           0x0      0
ret1           0x7b0407e8       2063861736
sp             0x7aece090       2062344336
r31            0x4001b4c0       1073853632
sar            0x10     16
pcoqh          0x7aee0f63       2062421859
pcsqh          0xbc9c400        197772288
pcoqt          0x7aee0f67       2062421863
pcsqt          0xbc9c400        197772288
eiem           0xffffffff       4294967295
iir            0x10004  65540
isr            0x102400ee       270794990
ior            0x966dc1d8       2523775448
ipsw           0x4001f  262175
goto           0x2      2
sr4            0xbc9c400        197772288
sr0            0xbc9c400        197772288
sr1            0x0      0
sr2            0x0      0
sr3            0x0      0
sr5            0x25bbc00        39566336
sr6            0x3880c00        59247616
sr7            0x3880c00        59247616
cr0            0x0      0
cr8            0x0      0
cr9            0x0      0
ccr            0x0      0
cr12           0x0      0
cr13           0x0      0
cr24           0x0      0
cr25           0x0      0
cr26           0x0      0
mpsfu_high     0x4001f4c0       1073870016
mpsfu_low      0x0      0
mpsfu_ovflo    0x0      0
pad            0x0      0
fpsr           0x8000000        134217728
fpe1           0x0      0
fpe2           0x0      0
fpe3           0x0      0
fpe4           0x0      0
fpe5           0x0      0
fpe6           0x0      0
fpe7           0x0      0


[-- Attachment #3: frame6.txt --]
[-- Type: text/plain, Size: 2279 bytes --]

flags          0x29000041       687865921
r1             0x7aece150       2062344528
rp             0x7aee0f0b       2062421771
r3             0x0      0
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x7aece110       2062344464
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
r16            0x0      0
r17            0x0      0
r18            0x0      0
r19            0x0      0
r20            0xf      15
r21            0x0      0
r22            0x0      0
r23            0x0      0
r24            0x1      1
r25            0x4001b4c0       1073853632
r26            0x4001c3b8       1073857464
dp             0x40010998       1073809816
ret0           0x0      0
ret1           0x7b0407e8       2063861736
sp             0x7aece050       2062344272
r31            0x4001b4c0       1073853632
sar            0x10     16
pcoqh          0x7aee0f0b       2062421771
pcsqh          0xbc9c400        197772288
pcoqt          0x7aee0f0f       2062421775
pcsqt          0xbc9c400        197772288
eiem           0xffffffff       4294967295
iir            0x10004  65540
isr            0x102400ee       270794990
ior            0x966dc1d8       2523775448
ipsw           0x4001f  262175
goto           0x2      2
sr4            0xbc9c400        197772288
sr0            0xbc9c400        197772288
sr1            0x0      0
sr2            0x0      0
sr3            0x0      0
sr5            0x25bbc00        39566336
sr6            0x3880c00        59247616
sr7            0x3880c00        59247616
cr0            0x0      0
cr8            0x0      0
cr9            0x0      0
ccr            0x0      0
cr12           0x0      0
cr13           0x0      0
cr24           0x0      0
cr25           0x0      0
cr26           0x0      0
mpsfu_high     0x4001f4c0       1073870016
mpsfu_low      0x0      0
mpsfu_ovflo    0x0      0
pad            0x0      0
fpsr           0x8000000        134217728
fpe1           0x0      0
fpe2           0x0      0
fpe3           0x0      0
fpe4           0x0      0
fpe5           0x0      0
fpe6           0x0      0
fpe7           0x0      0


[-- Attachment #4: disass.txt --]
[-- Type: text/plain, Size: 18499 bytes --]

Dump of assembler code for function __pthread_create_system:
0x7aee0b40 <__pthread_create_system+0>: stw rp,-14(,sp)
0x7aee0b44 <__pthread_create_system+4>: stw,ma r3,c0(,sp)
0x7aee0b48 <__pthread_create_system+8>: stw r4,-bc(,sp)
0x7aee0b4c <__pthread_create_system+12>:        stw r5,-b8(,sp)
0x7aee0b50 <__pthread_create_system+16>:        stw r6,-b4(,sp)
0x7aee0b54 <__pthread_create_system+20>:        stw r7,-b0(,sp)
0x7aee0b58 <__pthread_create_system+24>:        ldw -6c(,r19),r31
0x7aee0b5c <__pthread_create_system+28>:        mfctl tr3,r5
0x7aee0b60 <__pthread_create_system+32>:        ldo 0(r26),r3
0x7aee0b64 <__pthread_create_system+36>:        stw r19,-20(,sp)
0x7aee0b68 <__pthread_create_system+40>:        ldw r31(,r5),r5
0x7aee0b6c <__pthread_create_system+44>:        ldo 0(r25),r4
0x7aee0b70 <__pthread_create_system+48>:        ldo 0(r24),r6
0x7aee0b74 <__pthread_create_system+52>:        cmpb,= r0,r26,0x7aee0c1c <__pthread_create_system+220>
0x7aee0b78 <__pthread_create_system+56>:        ldo 0(r23),r7
0x7aee0b7c <__pthread_create_system+60>:        cmpb,=,n r0,r6,0x7aee0c1c <__pthread_create_system+220>
0x7aee0b80 <__pthread_create_system+64>:        cmpb,<> r4,r0,0x7aee0bb4 <__pthread_create_system+116>
0x7aee0b84 <__pthread_create_system+68>:        nop
0x7aee0b88 <__pthread_create_system+72>:        ldw -40(,r19),r23
0x7aee0b8c <__pthread_create_system+76>:        ldi 41,r24
0x7aee0b90 <__pthread_create_system+80>:        ldo -90(sp),r31
0x7aee0b94 <__pthread_create_system+84>:        ldw,ma 4(,r23),r20
0x7aee0b98 <__pthread_create_system+88>:        stw,ma r20,4(,r31)
0x7aee0b9c <__pthread_create_system+92>:        ldw,ma 4(,r23),r21
0x7aee0ba0 <__pthread_create_system+96>:        addib,> -8,r24,0x7aee0b94 <__pthread_create_system+84>
0x7aee0ba4 <__pthread_create_system+100>:       stw,ma r21,4(,r31)
0x7aee0ba8 <__pthread_create_system+104>:       ldw 0(,r23),r23
0x7aee0bac <__pthread_create_system+108>:       b,l 0x7aee0c04 <__pthread_create_system+196>,r0
0x7aee0bb0 <__pthread_create_system+112>:       stw r23,0(,r31)
0x7aee0bb4 <__pthread_create_system+116>:       ldw -24(,r19),r26
0x7aee0bb8 <__pthread_create_system+120>:       b,l 0x7aee5dec <__spin_lock>,rp
0x7aee0bbc <__pthread_create_system+124>:       stw r26,-a8(,sp)
0x7aee0bc0 <__pthread_create_system+128>:       ldw -20(,sp),r19
0x7aee0bc4 <__pthread_create_system+132>:       b,l 0x7aee8518 <__pthread_attr_id_lookup>,rp
0x7aee0bc8 <__pthread_create_system+136>:       ldw 0(,r4),r26
0x7aee0bcc <__pthread_create_system+140>:       ldw -20(,sp),r19
0x7aee0bd0 <__pthread_create_system+144>:       cmpb,=,n r0,ret0,0x7aee0c40 <__pthread_create_system+256>
0x7aee0bd4 <__pthread_create_system+148>:       ldi 41,r23
0x7aee0bd8 <__pthread_create_system+152>:       ldo -90(sp),r31
0x7aee0bdc <__pthread_create_system+156>:       ldw,ma 4(,ret0),r24
0x7aee0be0 <__pthread_create_system+160>:       ldw,ma 4(,ret0),r25
0x7aee0be4 <__pthread_create_system+164>:       stw,ma r24,4(,r31)
0x7aee0be8 <__pthread_create_system+168>:       addib,> -8,r23,0x7aee0bdc <__pthread_create_system+156>
0x7aee0bec <__pthread_create_system+172>:       stw,ma r25,4(,r31)
0x7aee0bf0 <__pthread_create_system+176>:       ldw 0(,ret0),r1
0x7aee0bf4 <__pthread_create_system+180>:       stw r1,0(,r31)
0x7aee0bf8 <__pthread_create_system+184>:       b,l 0x7aee5fa8 <__spin_unlock>,rp
0x7aee0bfc <__pthread_create_system+188>:       ldw -a8(,sp),r26
0x7aee0c00 <__pthread_create_system+192>:       ldw -20(,sp),r19
0x7aee0c04 <__pthread_create_system+196>:       b,l 0x7aee0464 <__pthread_id_lookup+84>,rp
0x7aee0c08 <__pthread_create_system+200>:       ldo -90(sp),r26
0x7aee0c0c <__pthread_create_system+204>:       ldw -20(,sp),r19
0x7aee0c10 <__pthread_create_system+208>:       cmpb,<> ret0,r0,0x7aee0c54 <__pthread_create_system+276>
0x7aee0c14 <__pthread_create_system+212>:       ldo 0(ret0),r4
0x7aee0c18 <__pthread_create_system+216>:       depwi,z,tr b,31,32,r3
0x7aee0c1c <__pthread_create_system+220>:       ldi 16,r3
0x7aee0c20 <__pthread_create_system+224>:       ldo 0(r3),ret0
0x7aee0c24 <__pthread_create_system+228>:       ldw -d4(,sp),rp
0x7aee0c28 <__pthread_create_system+232>:       ldw -b0(,sp),r7
0x7aee0c2c <__pthread_create_system+236>:       ldw -b4(,sp),r6
0x7aee0c30 <__pthread_create_system+240>:       ldw -b8(,sp),r5
0x7aee0c34 <__pthread_create_system+244>:       ldw -bc(,sp),r4
0x7aee0c38 <__pthread_create_system+248>:       bv r0(rp)
0x7aee0c3c <__pthread_create_system+252>:       ldw,mb -c0(,sp),r3
0x7aee0c40 <__pthread_create_system+256>:       b,l 0x7aee5fa8 <__spin_unlock>,rp
0x7aee0c44 <__pthread_create_system+260>:       ldw -a8(,sp),r26
0x7aee0c48 <__pthread_create_system+264>:       ldw -20(,sp),r19
0x7aee0c4c <__pthread_create_system+268>:       b,l 0x7aee0c20 <__pthread_create_system+224>,r0
0x7aee0c50 <__pthread_create_system+272>:       ldi 16,r3
0x7aee0c54 <__pthread_create_system+276>:       b,l 0x7aee2234 <__vp_alloc>,rp
0x7aee0c58 <__pthread_create_system+280>:       nop
0x7aee0c5c <__pthread_create_system+284>:       ldw -20(,sp),r19
0x7aee0c60 <__pthread_create_system+288>:       cmpb,<> ret0,r0,0x7aee0c88 <__pthread_create_system+328>
0x7aee0c64 <__pthread_create_system+292>:       nop
0x7aee0c68 <__pthread_create_system+296>:       b,l 0x7aee5dec <__spin_lock>,rp
0x7aee0c6c <__pthread_create_system+300>:       ldo 14(r4),r26
0x7aee0c70 <__pthread_create_system+304>:       ldw -20(,sp),r19
0x7aee0c74 <__pthread_create_system+308>:       b,l 0x7aee074c <__pthread_free>,rp
0x7aee0c78 <__pthread_create_system+312>:       ldo 0(r4),r26
0x7aee0c7c <__pthread_create_system+316>:       ldw -20(,sp),r19
0x7aee0c80 <__pthread_create_system+320>:       movib,tr b,r3,0x7aee0c24 <__pthread_create_system+228>
0x7aee0c84 <__pthread_create_system+324>:       ldo 0(r3),ret0
0x7aee0c88 <__pthread_create_system+328>:       stw r4,8(,ret0)
0x7aee0c8c <__pthread_create_system+332>:       ldw 8(,r4),r31
0x7aee0c90 <__pthread_create_system+336>:       depwi -1,30,1,r31
0x7aee0c94 <__pthread_create_system+340>:       depwi 0,31,1,r31
0x7aee0c98 <__pthread_create_system+344>:       stw r31,8(,r4)
0x7aee0c9c <__pthread_create_system+348>:       depwi -1,31,1,r31
0x7aee0ca0 <__pthread_create_system+352>:       ldw 64(,r4),rp
0x7aee0ca4 <__pthread_create_system+356>:       stw ret0,10(,r4)
0x7aee0ca8 <__pthread_create_system+360>:       ldw -80(,sp),r22
0x7aee0cac <__pthread_create_system+364>:       cmpiclr,<> de,r22,r0
0x7aee0cb0 <__pthread_create_system+368>:       stw r31,8(,r4)
0x7aee0cb4 <__pthread_create_system+372>:       ldb 5c(,r4),r22
0x7aee0cb8 <__pthread_create_system+376>:       depw r0,25,1,r22
0x7aee0cbc <__pthread_create_system+380>:       extrw,u r22,31,8,r21
0x7aee0cc0 <__pthread_create_system+384>:       stw r0,60(,r4)
0x7aee0cc4 <__pthread_create_system+388>:       depwi -1,24,1,r21
0x7aee0cc8 <__pthread_create_system+392>:       extrw,u r21,31,8,r31
0x7aee0ccc <__pthread_create_system+396>:       depw r0,26,1,r31
0x7aee0cd0 <__pthread_create_system+400>:       stb r31,5c(,r4)
0x7aee0cd4 <__pthread_create_system+404>:       stw r0,0(,rp)
0x7aee0cd8 <__pthread_create_system+408>:       stw r6,38(,r4)
0x7aee0cdc <__pthread_create_system+412>:       stw r7,3c(,r4)
0x7aee0ce0 <__pthread_create_system+416>:       ldw -54(,sp),r31
0x7aee0ce4 <__pthread_create_system+420>:       cmpib,<> -3,r31,0x7aee0d08 <__pthread_create_system+456>
0x7aee0ce8 <__pthread_create_system+424>:       nop
0x7aee0cec <__pthread_create_system+428>:       ldw c8(,r5),r25
0x7aee0cf0 <__pthread_create_system+432>:       stw r25,c8(,r4)
0x7aee0cf4 <__pthread_create_system+436>:       ldw cc(,r5),r26
0x7aee0cf8 <__pthread_create_system+440>:       stw r26,cc(,r4)
0x7aee0cfc <__pthread_create_system+444>:       ldw 70(,r5),r26
0x7aee0d00 <__pthread_create_system+448>:       b,l 0x7aee0d28 <__pthread_create_system+488>,r0
0x7aee0d04 <__pthread_create_system+452>:       ldw 74(,r5),r25
0x7aee0d08 <__pthread_create_system+456>:       stw r31,c8(,r4)
0x7aee0d0c <__pthread_create_system+460>:       ldw 8(,r4),r24
0x7aee0d10 <__pthread_create_system+464>:       depwi -1,24,1,r24
0x7aee0d14 <__pthread_create_system+468>:       ldw -50(,sp),ret0
0x7aee0d18 <__pthread_create_system+472>:       stw ret0,cc(,r4)
0x7aee0d1c <__pthread_create_system+476>:       stw r24,8(,r4)
0x7aee0d20 <__pthread_create_system+480>:       ldw 70(,r5),r26
0x7aee0d24 <__pthread_create_system+484>:       ldw 74(,r5),r25
0x7aee0d28 <__pthread_create_system+488>:       stw r26,70(,r4)
0x7aee0d2c <__pthread_create_system+492>:       ldw 78(,r5),r26
0x7aee0d30 <__pthread_create_system+496>:       stw r25,74(,r4)
0x7aee0d34 <__pthread_create_system+500>:       ldw 7c(,r5),ret1
0x7aee0d38 <__pthread_create_system+504>:       stw r26,78(,r4)
0x7aee0d3c <__pthread_create_system+508>:       ldw 80(,r5),r20
0x7aee0d40 <__pthread_create_system+512>:       stw ret1,7c(,r4)
0x7aee0d44 <__pthread_create_system+516>:       ldw 84(,r5),r21
0x7aee0d48 <__pthread_create_system+520>:       stw r20,80(,r4)
0x7aee0d4c <__pthread_create_system+524>:       ldw 88(,r5),r22
0x7aee0d50 <__pthread_create_system+528>:       stw r21,84(,r4)
0x7aee0d54 <__pthread_create_system+532>:       ldw 8c(,r5),ret1
0x7aee0d58 <__pthread_create_system+536>:       stw r22,88(,r4)
0x7aee0d5c <__pthread_create_system+540>:       stw ret1,8c(,r4)
0x7aee0d60 <__pthread_create_system+544>:       ldw -7c(,sp),r23
0x7aee0d64 <__pthread_create_system+548>:       bb,>= r23,1b,0x7aee0db8 <__pthread_create_system+632>
0x7aee0d68 <__pthread_create_system+552>:       nop
0x7aee0d6c <__pthread_create_system+556>:       ldw a4(,r5),ret1
0x7aee0d70 <__pthread_create_system+560>:       stw ret1,a4(,r4)
0x7aee0d74 <__pthread_create_system+564>:       ldw a8(,r5),r20
0x7aee0d78 <__pthread_create_system+568>:       ldw ac(,r5),ret0
0x7aee0d7c <__pthread_create_system+572>:       stw r20,a8(,r4)
0x7aee0d80 <__pthread_create_system+576>:       ldw b0(,r5),r1
0x7aee0d84 <__pthread_create_system+580>:       stw ret0,ac(,r4)
0x7aee0d88 <__pthread_create_system+584>:       ldw b4(,r5),rp
0x7aee0d8c <__pthread_create_system+588>:       stw r1,b0(,r4)
0x7aee0d90 <__pthread_create_system+592>:       ldw b8(,r5),r6
0x7aee0d94 <__pthread_create_system+596>:       stw rp,b4(,r4)
0x7aee0d98 <__pthread_create_system+600>:       ldw bc(,r5),r7
0x7aee0d9c <__pthread_create_system+604>:       stw r6,b8(,r4)
0x7aee0da0 <__pthread_create_system+608>:       ldw c0(,r5),r31
0x7aee0da4 <__pthread_create_system+612>:       stw r7,bc(,r4)
0x7aee0da8 <__pthread_create_system+616>:       ldw c4(,r5),r21
0x7aee0dac <__pthread_create_system+620>:       stw r31,c0(,r4)
0x7aee0db0 <__pthread_create_system+624>:       b,l 0x7aee0e0c <__pthread_create_system+716>,r0
0x7aee0db4 <__pthread_create_system+628>:       stw r21,c4(,r4)
0x7aee0db8 <__pthread_create_system+632>:       ldw -78(,sp),r24
0x7aee0dbc <__pthread_create_system+636>:       stw r24,a4(,r4)
0x7aee0dc0 <__pthread_create_system+640>:       ldw -74(,sp),r22
0x7aee0dc4 <__pthread_create_system+644>:       ldw -70(,sp),r23
0x7aee0dc8 <__pthread_create_system+648>:       stw r22,a8(,r4)
0x7aee0dcc <__pthread_create_system+652>:       ldw -6c(,sp),r24
0x7aee0dd0 <__pthread_create_system+656>:       stw r23,ac(,r4)
0x7aee0dd4 <__pthread_create_system+660>:       ldw -68(,sp),r25
0x7aee0dd8 <__pthread_create_system+664>:       stw r24,b0(,r4)
0x7aee0ddc <__pthread_create_system+668>:       ldw -64(,sp),r26
0x7aee0de0 <__pthread_create_system+672>:       stw r25,b4(,r4)
0x7aee0de4 <__pthread_create_system+676>:       ldw -60(,sp),ret1
0x7aee0de8 <__pthread_create_system+680>:       stw r26,b8(,r4)
0x7aee0dec <__pthread_create_system+684>:       ldw -5c(,sp),r1
0x7aee0df0 <__pthread_create_system+688>:       stw ret1,bc(,r4)
0x7aee0df4 <__pthread_create_system+692>:       ldw 8(,r4),r24
0x7aee0df8 <__pthread_create_system+696>:       depwi -1,25,1,r24
0x7aee0dfc <__pthread_create_system+700>:       ldw -58(,sp),r20
0x7aee0e00 <__pthread_create_system+704>:       stw r1,c0(,r4)
0x7aee0e04 <__pthread_create_system+708>:       stw r20,c4(,r4)
0x7aee0e08 <__pthread_create_system+712>:       stw r24,8(,r4)
0x7aee0e0c <__pthread_create_system+716>:       ldw -4(,r19),r26
0x7aee0e10 <__pthread_create_system+720>:       stw r26,-a4(,sp)
0x7aee0e14 <__pthread_create_system+724>:       ldi 1,r6
0x7aee0e18 <__pthread_create_system+728>:       ldi 1,r7
0x7aee0e1c <__pthread_create_system+732>:       b,l 0x7aee5dec <__spin_lock>,rp
0x7aee0e20 <__pthread_create_system+736>:       stw r6,c(,r4)
0x7aee0e24 <__pthread_create_system+740>:       ldw -20(,sp),r19
0x7aee0e28 <__pthread_create_system+744>:       stw r7,a0(,r4)
0x7aee0e2c <__pthread_create_system+748>:       b,l 0x7aee02a0 <__libc_reinit+364>,rp
0x7aee0e30 <__pthread_create_system+752>:       ldo 0(r4),r26
0x7aee0e34 <__pthread_create_system+756>:       ldw -20(,sp),r19
0x7aee0e38 <__pthread_create_system+760>:       stw ret0,0(,r3)
0x7aee0e3c <__pthread_create_system+764>:       ldw 94(,r5),r31
0x7aee0e40 <__pthread_create_system+768>:       ldo 0(r4),r26
0x7aee0e44 <__pthread_create_system+772>:       b,l 0x7aee014c <__libc_reinit+24>,rp
0x7aee0e48 <__pthread_create_system+776>:       stw r31,98(,r4)
0x7aee0e4c <__pthread_create_system+780>:       ldw -20(,sp),r19
0x7aee0e50 <__pthread_create_system+784>:       ldw -10(,r19),r23
0x7aee0e54 <__pthread_create_system+788>:       stw r23,0(,r4)
0x7aee0e58 <__pthread_create_system+792>:       ldw 4(,r23),rp
0x7aee0e5c <__pthread_create_system+796>:       stw rp,4(,r4)
0x7aee0e60 <__pthread_create_system+800>:       ldw 4(,r23),r1
0x7aee0e64 <__pthread_create_system+804>:       stw r4,0(,r1)
0x7aee0e68 <__pthread_create_system+808>:       stw r4,4(,r23)
0x7aee0e6c <__pthread_create_system+812>:       ldw -18(,r19),r3
0x7aee0e70 <__pthread_create_system+816>:       ldw 0(,r3),ret0
0x7aee0e74 <__pthread_create_system+820>:       ldw 20(,r19),ret1
0x7aee0e78 <__pthread_create_system+824>:       ldo 1(ret0),rp
0x7aee0e7c <__pthread_create_system+828>:       stw rp,0(,r3)
0x7aee0e80 <__pthread_create_system+832>:       ldw 0(,ret1),r3
0x7aee0e84 <__pthread_create_system+836>:       ldo 1(r3),r5
0x7aee0e88 <__pthread_create_system+840>:       stw r5,0(,ret1)
0x7aee0e8c <__pthread_create_system+844>:       b,l 0x7aee5fa8 <__spin_unlock>,rp
0x7aee0e90 <__pthread_create_system+848>:       ldw -a4(,sp),r26
0x7aee0e94 <__pthread_create_system+852>:       ldw -20(,sp),r19
0x7aee0e98 <__pthread_create_system+856>:       ldw -60(,r19),r20
0x7aee0e9c <__pthread_create_system+860>:       ldi 1,r21
0x7aee0ea0 <__pthread_create_system+864>:       stw r21,0(,r20)
0x7aee0ea4 <__pthread_create_system+868>:       ldo 0(r4),r26
0x7aee0ea8 <__pthread_create_system+872>:       ldw 98(,r19),r22
0x7aee0eac <__pthread_create_system+876>:       b,l 0x7aee2280 <__vp_create>,rp
0x7aee0eb0 <__pthread_create_system+880>:       ldw 0(,r22),r25
0x7aee0eb4 <__pthread_create_system+884>:       ldw -20(,sp),r19
0x7aee0eb8 <__pthread_create_system+888>:       cmpb,= ret0,r0,0x7aee0ee8 <__pthread_create_system+936>
0x7aee0ebc <__pthread_create_system+892>:       ldo 0(ret0),r3
0x7aee0ec0 <__pthread_create_system+896>:       b,l 0x7aee5dec <__spin_lock>,rp
0x7aee0ec4 <__pthread_create_system+900>:       ldo 14(r4),r26
0x7aee0ec8 <__pthread_create_system+904>:       ldw -20(,sp),r19
0x7aee0ecc <__pthread_create_system+908>:       b,l 0x7aee074c <__pthread_free>,rp
0x7aee0ed0 <__pthread_create_system+912>:       ldo 0(r4),r26
0x7aee0ed4 <__pthread_create_system+916>:       ldw -20(,sp),r19
0x7aee0ed8 <__pthread_create_system+920>:       cmpiclr,<> e,r3,r0
0x7aee0edc <__pthread_create_system+924>:       ldi 16,r3
0x7aee0ee0 <__pthread_create_system+928>:       b,l 0x7aee0c24 <__pthread_create_system+228>,r0
0x7aee0ee4 <__pthread_create_system+932>:       ldo 0(r3),ret0
0x7aee0ee8 <__pthread_create_system+936>:       ldo 0(r4),r25
0x7aee0eec <__pthread_create_system+940>:       b,l 0x7aee2104 <_pthread_callback_np+340>,rp
0x7aee0ef0 <__pthread_create_system+944>:       ldi 1,r26
0x7aee0ef4 <__pthread_create_system+948>:       ldw -20(,sp),r19
0x7aee0ef8 <__pthread_create_system+952>:       movb,tr r0,r3,0x7aee0c24 <__pthread_create_system+228>
0x7aee0efc <__pthread_create_system+956>:       ldo 0(r3),ret0
0x7aee0f00 <__pthread_create_system+960>:       b,l 0x7aee0f18 <__pthread_create_system+984>,rp
0x7aee0f04 <__pthread_create_system+964>:       nop
0x7aee0f08 <__pthread_create_system+968>:       ldw -18(,sp),rp
0x7aee0f0c <__pthread_create_system+972>:       ldsid (,rp),r1
0x7aee0f10 <__pthread_create_system+976>:       mtsp r1,sr0
0x7aee0f14 <__pthread_create_system+980>:       be,n 0(sr0,rp)
0x7aee0f18 <__pthread_create_system+984>:       stw rp,-14(,sp)
0x7aee0f1c <__pthread_create_system+988>:       stw,ma r3,40(,sp)
0x7aee0f20 <__pthread_create_system+992>:       ldo 0(r26),r3
0x7aee0f24 <__pthread_create_system+996>:       stw r19,-20(,sp)
0x7aee0f28 <__pthread_create_system+1000>:      ldw 8(,r26),r31
0x7aee0f2c <__pthread_create_system+1004>:      bb,>= r31,f,0x7aee0f40 <__pthread_create_system+1024>
0x7aee0f30 <__pthread_create_system+1008>:      nop
0x7aee0f34 <__pthread_create_system+1012>:      b,l 0x7aee014c <__libc_reinit+24>,rp
0x7aee0f38 <__pthread_create_system+1016>:      ldo 0(r3),r26
0x7aee0f3c <__pthread_create_system+1020>:      ldw -20(,sp),r19
0x7aee0f40 <__pthread_create_system+1024>:      ldi 2,r26
0x7aee0f44 <__pthread_create_system+1028>:      b,l 0x7aee2104 <_pthread_callback_np+340>,rp
0x7aee0f48 <__pthread_create_system+1032>:      ldo 0(r3),r25
0x7aee0f4c <__pthread_create_system+1036>:      ldw -20(,sp),r19
0x7aee0f50 <__pthread_create_system+1040>:      ldw 38(,r3),r22
0x7aee0f54 <__pthread_create_system+1044>:      ldw 3c(,r3),r26
0x7aee0f58 <__pthread_create_system+1048>:      b,l 0x7aedcce4 <$$dyncall_external>,r31
0x7aee0f5c <__pthread_create_system+1052>:      ldo 0(r31),rp
0x7aee0f60 <__pthread_create_system+1056>:      ldw -20(,sp),r19
0x7aee0f64 <__pthread_create_system+1060>:      stw ret0,40(,r3)
0x7aee0f68 <__pthread_create_system+1064>:      b,l 0x7aee1308 <pthread_exit>,rp
0x7aee0f6c <__pthread_create_system+1068>:      ldo 0(ret0),r26
0x7aee0f70 <__pthread_create_system+1072>:      ldw -20(,sp),r19
0x7aee0f74 <__pthread_create_system+1076>:      ldw -54(,sp),rp
0x7aee0f78 <__pthread_create_system+1080>:      bv r0(rp)
0x7aee0f7c <__pthread_create_system+1084>:      ldw,mb -40(,sp),r3

Re: [RFC] Infinite backtraces...

[Randolph Chung]

> > 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"?

argh, i was wrong... the stub unwinder handles the case when pc == 0,
and then it assumes that the rp doesn't get modified by default.

there's also a bug in the outer __pthread_create_system frame; the stub
unwinder doesn't set the rp appropriately. can you try the attached
patch? it should convert your infinite backtrace into an error ;-)

randolph



2004-12-03  Randolph Chung  <tausq@debian.org>

	* hppa-tdep.c (hppa_stub_frame_unwind_cache): Set RP appropriately
	for export stub frames.

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.182
diff -u -p -r1.182 hppa-tdep.c
--- hppa-tdep.c	23 Nov 2004 21:05:20 -0000	1.182
+++ hppa-tdep.c	3 Dec 2004 17:56:56 -0000
@@ -2119,8 +2120,9 @@ hppa_stub_frame_unwind_cache (struct fra
       if (u && u->stub_unwind.stub_type == EXPORT)
 	{
           info->saved_regs[HPPA_PCOQ_HEAD_REGNUM].addr = info->base - 24;
+          info->saved_regs[HPPA_RP_REGNUM].addr = info->base - 24;
 
 	  return info;
 	}
     }
 

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

> argh, i was wrong... the stub unwinder handles the case when pc == 0,
> and then it assumes that the rp doesn't get modified by default.

OK.

> there's also a bug in the outer __pthread_create_system frame; the stub
> unwinder doesn't set the rp appropriately. can you try the attached
> patch? it should convert your infinite backtrace into an error ;-)

I gave it a try. I see the error, but a bit too early. That's because
I have a stub in the middle of my call stack. Here is what I get now:

    (gdb) bt
    #0  simple.break_me () at simple.adb:27
    #1  0x0000a2cc in simple.caller (<_task>=0x4001c3a0) at simple.adb:21
    #2  0x0000a268 in simple__callerB___2 () at simple.adb:18
    #3  0x0000a268 in simple__callerB___2 () at simple.adb:18
    warning: Previous frame identical to this frame (corrupt stack?)

(this was with 6.3, do you think HEAD would behave better?)

-- 
Joel

Re: [RFC] Infinite backtraces...

[Randolph Chung]

> I gave it a try. I see the error, but a bit too early. That's because
> I have a stub in the middle of my call stack. Here is what I get now:

argh, yes, well, the patch is buggy :P

> (this was with 6.3, do you think HEAD would behave better?)

nah. let me work on this a bit more.

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

Re: [RFC] Infinite backtraces...

[Randolph Chung]

How about something like this to prevent infinite unwindings from pc==0
frames?

(note for reviewers: the stub frame unwinder is selected for frames
where pc == 0)

randolph

2004-12-05  Randolph Chung  <tausq@debian.org>

	* hppa-tdep.c (hppa_stub_Frame_unwind_cache): Stop unwinding if 
	unwinding from a frame with pc == 0.
	(hppa_stub_frame_this_id): Likewise.
	(hppa_stub_frame_prev_register): Only provide real values if the frame
	cache is not NULL.

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.185
diff -u -p -r1.185 hppa-tdep.c
--- hppa-tdep.c	6 Dec 2004 03:32:26 -0000	1.185
+++ hppa-tdep.c	6 Dec 2004 07:11:29 -0000
@@ -2111,10 +2115,13 @@ hppa_stub_frame_unwind_cache (struct fra
   struct gdbarch *gdbarch = get_frame_arch (next_frame);
   struct hppa_stub_unwind_cache *info;
   struct unwind_table_entry *u;
 
   if (*this_cache)
     return *this_cache;
 
+  if (frame_pc_unwind (next_frame) == 0)
+    return NULL;
+
   info = FRAME_OBSTACK_ZALLOC (struct hppa_stub_unwind_cache);
   *this_cache = info;
   info->saved_regs = trad_frame_alloc_saved_regs (next_frame);
@@ -2149,7 +2164,11 @@ hppa_stub_frame_this_id (struct frame_in
 {
   struct hppa_stub_unwind_cache *info
     = hppa_stub_frame_unwind_cache (next_frame, this_prologue_cache);
-  *this_id = frame_id_build (info->base, frame_pc_unwind (next_frame));
+
+  if (info)
+    *this_id = frame_id_build (info->base, frame_pc_unwind (next_frame));
+  else
+    *this_id = null_frame_id;
 }
 
 static void
@@ -2161,8 +2180,11 @@ hppa_stub_frame_prev_register (struct fr
 {
   struct hppa_stub_unwind_cache *info
     = hppa_stub_frame_unwind_cache (next_frame, this_prologue_cache);
-  hppa_frame_prev_register_helper (next_frame, info->saved_regs, regnum,
-		                   optimizedp, lvalp, addrp, realnump, valuep);
+
+  if (info)
+    hppa_frame_prev_register_helper (next_frame, info->saved_regs, regnum,
+				     optimizedp, lvalp, addrp, realnump, 
+				     valuep);
 }
 
 static const struct frame_unwind hppa_stub_frame_unwind = {

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

Hello Randolph,

> 2004-12-05  Randolph Chung  <tausq@debian.org>
> 
> 	* hppa-tdep.c (hppa_stub_Frame_unwind_cache): Stop unwinding if 
> 	unwinding from a frame with pc == 0.
> 	(hppa_stub_frame_this_id): Likewise.
> 	(hppa_stub_frame_prev_register): Only provide real values if the frame
> 	cache is not NULL.

I haven't tested this patch yet, but it looks pretty good, as it is
close to something that I did on my side. Just a question: What happens
if hppa_stub_frame_prev_register() doesn't set anything?

You added "if (info) then hppa_frame_prev ().". Could it ever happen
that info is NULL?

One thing that I'm thinking is that this will no longer stop the
backtrace once your change to hide the stubs goes in (except in
the very unlikely case when we're inside the initial stub). Is it
still worth including this patch under these conditions?

> Index: hppa-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
> retrieving revision 1.185
> diff -u -p -r1.185 hppa-tdep.c
> --- hppa-tdep.c	6 Dec 2004 03:32:26 -0000	1.185
> +++ hppa-tdep.c	6 Dec 2004 07:11:29 -0000
> @@ -2111,10 +2115,13 @@ hppa_stub_frame_unwind_cache (struct fra
>    struct gdbarch *gdbarch = get_frame_arch (next_frame);
>    struct hppa_stub_unwind_cache *info;
>    struct unwind_table_entry *u;
>  
>    if (*this_cache)
>      return *this_cache;
>  
> +  if (frame_pc_unwind (next_frame) == 0)
> +    return NULL;
> +
>    info = FRAME_OBSTACK_ZALLOC (struct hppa_stub_unwind_cache);
>    *this_cache = info;
>    info->saved_regs = trad_frame_alloc_saved_regs (next_frame);
> @@ -2149,7 +2164,11 @@ hppa_stub_frame_this_id (struct frame_in
>  {
>    struct hppa_stub_unwind_cache *info
>      = hppa_stub_frame_unwind_cache (next_frame, this_prologue_cache);
> -  *this_id = frame_id_build (info->base, frame_pc_unwind (next_frame));
> +
> +  if (info)
> +    *this_id = frame_id_build (info->base, frame_pc_unwind (next_frame));
> +  else
> +    *this_id = null_frame_id;
>  }
>  
>  static void
> @@ -2161,8 +2180,11 @@ hppa_stub_frame_prev_register (struct fr
>  {
>    struct hppa_stub_unwind_cache *info
>      = hppa_stub_frame_unwind_cache (next_frame, this_prologue_cache);
> -  hppa_frame_prev_register_helper (next_frame, info->saved_regs, regnum,
> -		                   optimizedp, lvalp, addrp, realnump, valuep);
> +
> +  if (info)
> +    hppa_frame_prev_register_helper (next_frame, info->saved_regs, regnum,
> +				     optimizedp, lvalp, addrp, realnump, 
> +				     valuep);
>  }
>  
>  static const struct frame_unwind hppa_stub_frame_unwind = {

-- 
Joel

Re: [RFC] Infinite backtraces...

[Randolph Chung]

> if hppa_stub_frame_prev_register() doesn't set anything?
> 
> You added "if (info) then hppa_frame_prev ().". Could it ever happen
> that info is NULL?

i haven't seen it hit that case; i think since this_id is null_frame_id
in this case it will not query the frame for registers.  should i fill
in dummy values just in case?

> One thing that I'm thinking is that this will no longer stop the
> backtrace once your change to hide the stubs goes in (except in
> the very unlikely case when we're inside the initial stub). Is it
> still worth including this patch under these conditions?

why is that? even with my export stub change this is still applicable to
your threading case....

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

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

> i haven't seen it hit that case; i think since this_id is null_frame_id
> in this case it will not query the frame for registers.  should i fill
> in dummy values just in case?

I had the same analysis that it should never happen. If Andrew agrees,
I would recommend simply putting an assertion instead. Putting a dummy
value is not that satisfactory, as you don't know what this is going
to be used for.

> > One thing that I'm thinking is that this will no longer stop the
> > backtrace once your change to hide the stubs goes in (except in
> > the very unlikely case when we're inside the initial stub). Is it
> > still worth including this patch under these conditions?
> 
> why is that? even with my export stub change this is still applicable to
> your threading case....

I don't see how the stub unwinder code is going to be used if you
are going to be skipping them. The only case when it is going to
be used is when uwinding a program that was stopped just inside one.
No?

-- 
Joel

Re: [RFC] Infinite backtraces...

[Randolph Chung]

> I don't see how the stub unwinder code is going to be used if you
> are going to be skipping them. The only case when it is going to
> be used is when uwinding a program that was stopped just inside one.
> No?

not exactly...

1) it is used when stepping into a function called by a stub (this is
essential for software watchpointing; since there's hardware watch
pointing on hpux it may be less important)
2) it is used when the current frame's pc is 0

in this case, even if we skip the stub that calls the pthread start
function, the return from the real pthread_start function will still be
zero after you skip the stub, so we still need the stub unwinder to
return a null_frame_id to terminate the unwinding.

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

Re: [RFC] Infinite backtraces...

[Randolph Chung]

> I had the same analysis that it should never happen. If Andrew agrees,
> I would recommend simply putting an assertion instead. Putting a dummy
> value is not that satisfactory, as you don't know what this is going
> to be used for.

i've committed the following

2004-12-05  Randolph Chung  <tausq@debian.org>

	* hppa-tdep.c (hppa_stub_Frame_unwind_cache): Stop unwinding if 
	unwinding from a frame with pc == 0.
	(hppa_stub_frame_this_id): Likewise.
	(hppa_stub_frame_prev_register): Only provide real values if the frame
	cache is not NULL.

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.185
diff -u -p -r1.185 hppa-tdep.c
--- hppa-tdep.c	6 Dec 2004 03:32:26 -0000	1.185
+++ hppa-tdep.c	8 Dec 2004 01:41:08 -0000
@@ -2111,17 +2124,21 @@ hppa_stub_frame_unwind_cache (struct fra
   struct gdbarch *gdbarch = get_frame_arch (next_frame);
   struct hppa_stub_unwind_cache *info;
   struct unwind_table_entry *u;
 
   if (*this_cache)
     return *this_cache;
 
+  if (frame_pc_unwind (next_frame) == 0)
+    return NULL;
+
   info = FRAME_OBSTACK_ZALLOC (struct hppa_stub_unwind_cache);
   *this_cache = info;
   info->saved_regs = trad_frame_alloc_saved_regs (next_frame);
@@ -2149,7 +2173,11 @@ hppa_stub_frame_this_id (struct frame_in
 {
   struct hppa_stub_unwind_cache *info
     = hppa_stub_frame_unwind_cache (next_frame, this_prologue_cache);
-  *this_id = frame_id_build (info->base, frame_pc_unwind (next_frame));
+
+  if (info)
+    *this_id = frame_id_build (info->base, frame_func_unwind (next_frame));
+  else
+    *this_id = null_frame_id;
 }
 
 static void
@@ -2161,8 +2189,13 @@ hppa_stub_frame_prev_register (struct fr
 {
   struct hppa_stub_unwind_cache *info
     = hppa_stub_frame_unwind_cache (next_frame, this_prologue_cache);
-  hppa_frame_prev_register_helper (next_frame, info->saved_regs, regnum,
-		                   optimizedp, lvalp, addrp, realnump, valuep);
+
+  if (info)
+    hppa_frame_prev_register_helper (next_frame, info->saved_regs, regnum,
+				     optimizedp, lvalp, addrp, realnump, 
+				     valuep);
+  else
+    error ("Requesting registers from null frame.\n");
 }
 
 static const struct frame_unwind hppa_stub_frame_unwind = {

[commit] Move zero PC check to frame.c; Was: [RFC] Infinite backtraces...

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

Randolph Chung wrote:
>>I had the same analysis that it should never happen. If Andrew agrees,
>>I would recommend simply putting an assertion instead. Putting a dummy
>>value is not that satisfactory, as you don't know what this is going
>>to be used for.
> 
> 
> i've committed the following
> 
> 2004-12-05  Randolph Chung  <tausq@debian.org>
> 
> 	* hppa-tdep.c (hppa_stub_Frame_unwind_cache): Stop unwinding if 
> 	unwinding from a frame with pc == 0.
> 	(hppa_stub_frame_this_id): Likewise.
> 	(hppa_stub_frame_prev_register): Only provide real values if the frame
> 	cache is not NULL.

FYI,

> Index: hppa-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
> retrieving revision 1.185
> diff -u -p -r1.185 hppa-tdep.c
> --- hppa-tdep.c	6 Dec 2004 03:32:26 -0000	1.185
> +++ hppa-tdep.c	8 Dec 2004 01:41:08 -0000
> @@ -2111,17 +2124,21 @@ hppa_stub_frame_unwind_cache (struct fra
>    struct gdbarch *gdbarch = get_frame_arch (next_frame);
>    struct hppa_stub_unwind_cache *info;
>    struct unwind_table_entry *u;
>  
>    if (*this_cache)
>      return *this_cache;
>  
> +  if (frame_pc_unwind (next_frame) == 0)
> +    return NULL;
> +

I've checked in the attached.  This test is generic so might as well 
live in frame.c (you'll note that I've made the conditions on which it 
triggers more robust).

committed,
Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1685 bytes --]

2004-12-12  Andrew Cagney  <cagney@gnu.org>

	* frame.c (get_prev_frame): When unwinding normal frames, check
	that the PC isn't zero.
	* hppa-tdep.c (hppa_stub_frame_unwind_cache): Delete check for a
	zero PC.

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.196
diff -p -u -r1.196 frame.c
--- frame.c	8 Dec 2004 01:56:16 -0000	1.196
+++ frame.c	12 Dec 2004 16:23:55 -0000
@@ -1257,6 +1257,18 @@ get_prev_frame (struct frame_info *this_
       return NULL;
     }
 
+  /* Assume that the only way to get a zero PC is through something
+     like a SIGSEGV or a dummy frame, and hence that NORMAL frames
+     will never unwind a zero PC.  */
+  if (this_frame->level > 0
+      && get_frame_type (this_frame) == NORMAL_FRAME
+      && get_frame_type (get_next_frame (this_frame)) == NORMAL_FRAME
+      && get_frame_pc (this_frame) == 0)
+    {
+      frame_debug_got_null_frame (gdb_stdlog, this_frame, "zero PC");
+      return NULL;
+    }
+
   return get_prev_frame_1 (this_frame);
 }
 
Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.189
diff -p -u -r1.189 hppa-tdep.c
--- hppa-tdep.c	8 Dec 2004 06:12:40 -0000	1.189
+++ hppa-tdep.c	12 Dec 2004 16:23:57 -0000
@@ -2105,9 +2105,6 @@ hppa_stub_frame_unwind_cache (struct fra
   if (*this_cache)
     return *this_cache;
 
-  if (frame_pc_unwind (next_frame) == 0)
-    return NULL;
-
   info = FRAME_OBSTACK_ZALLOC (struct hppa_stub_unwind_cache);
   *this_cache = info;
   info->saved_regs = trad_frame_alloc_saved_regs (next_frame);

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

> > 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 #2: frame5.txt --]
[-- Type: text/plain, Size: 2283 bytes --]

flags          0x29000041       687865921
r1             0x7aece150       2062344528
rp             0x1705b  94299
r3             0x4001f3b0       1073869744
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x7aece110       2062344464
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
r16            0x0      0
r17            0x0      0
r18            0x0      0
r19            0x0      0
r20            0xf      15
r21            0x0      0
r22            0x0      0
r23            0x0      0
r24            0x1      1
r25            0x4001b4c0       1073853632
r26            0x4001c3b8       1073857464
dp             0x40010998       1073809816
ret0           0x0      0
ret1           0x7b0407e8       2063861736
sp             0x7aece090       2062344336
r31            0x4001b4c0       1073853632
sar            0x10     16
pcoqh          0x7aee0f63       2062421859
pcsqh          0xbc9c400        197772288
pcoqt          0x7aee0f67       2062421863
pcsqt          0xbc9c400        197772288
eiem           0xffffffff       4294967295
iir            0x10004  65540
isr            0x102400ee       270794990
ior            0x966dc1d8       2523775448
ipsw           0x4001f  262175
goto           0x2      2
sr4            0xbc9c400        197772288
sr0            0xbc9c400        197772288
sr1            0x0      0
sr2            0x0      0
sr3            0x0      0
sr5            0x25bbc00        39566336
sr6            0x3880c00        59247616
sr7            0x3880c00        59247616
cr0            0x0      0
cr8            0x0      0
cr9            0x0      0
ccr            0x0      0
cr12           0x0      0
cr13           0x0      0
cr24           0x0      0
cr25           0x0      0
cr26           0x0      0
mpsfu_high     0x4001f4c0       1073870016
mpsfu_low      0x0      0
mpsfu_ovflo    0x0      0
pad            0x0      0
fpsr           0x8000000        134217728
fpe1           0x0      0
fpe2           0x0      0
fpe3           0x0      0
fpe4           0x0      0
fpe5           0x0      0
fpe6           0x0      0
fpe7           0x0      0


[-- Attachment #3: frame6.txt --]
[-- Type: text/plain, Size: 2279 bytes --]

flags          0x29000041       687865921
r1             0x7aece150       2062344528
rp             0x7aee0f0b       2062421771
r3             0x0      0
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x7aece110       2062344464
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
r16            0x0      0
r17            0x0      0
r18            0x0      0
r19            0x0      0
r20            0xf      15
r21            0x0      0
r22            0x0      0
r23            0x0      0
r24            0x1      1
r25            0x4001b4c0       1073853632
r26            0x4001c3b8       1073857464
dp             0x40010998       1073809816
ret0           0x0      0
ret1           0x7b0407e8       2063861736
sp             0x7aece050       2062344272
r31            0x4001b4c0       1073853632
sar            0x10     16
pcoqh          0x7aee0f0b       2062421771
pcsqh          0xbc9c400        197772288
pcoqt          0x7aee0f0f       2062421775
pcsqt          0xbc9c400        197772288
eiem           0xffffffff       4294967295
iir            0x10004  65540
isr            0x102400ee       270794990
ior            0x966dc1d8       2523775448
ipsw           0x4001f  262175
goto           0x2      2
sr4            0xbc9c400        197772288
sr0            0xbc9c400        197772288
sr1            0x0      0
sr2            0x0      0
sr3            0x0      0
sr5            0x25bbc00        39566336
sr6            0x3880c00        59247616
sr7            0x3880c00        59247616
cr0            0x0      0
cr8            0x0      0
cr9            0x0      0
ccr            0x0      0
cr12           0x0      0
cr13           0x0      0
cr24           0x0      0
cr25           0x0      0
cr26           0x0      0
mpsfu_high     0x4001f4c0       1073870016
mpsfu_low      0x0      0
mpsfu_ovflo    0x0      0
pad            0x0      0
fpsr           0x8000000        134217728
fpe1           0x0      0
fpe2           0x0      0
fpe3           0x0      0
fpe4           0x0      0
fpe5           0x0      0
fpe6           0x0      0
fpe7           0x0      0


[-- Attachment #4: disass.txt --]
[-- Type: text/plain, Size: 18499 bytes --]

Dump of assembler code for function __pthread_create_system:
0x7aee0b40 <__pthread_create_system+0>: stw rp,-14(,sp)
0x7aee0b44 <__pthread_create_system+4>: stw,ma r3,c0(,sp)
0x7aee0b48 <__pthread_create_system+8>: stw r4,-bc(,sp)
0x7aee0b4c <__pthread_create_system+12>:        stw r5,-b8(,sp)
0x7aee0b50 <__pthread_create_system+16>:        stw r6,-b4(,sp)
0x7aee0b54 <__pthread_create_system+20>:        stw r7,-b0(,sp)
0x7aee0b58 <__pthread_create_system+24>:        ldw -6c(,r19),r31
0x7aee0b5c <__pthread_create_system+28>:        mfctl tr3,r5
0x7aee0b60 <__pthread_create_system+32>:        ldo 0(r26),r3
0x7aee0b64 <__pthread_create_system+36>:        stw r19,-20(,sp)
0x7aee0b68 <__pthread_create_system+40>:        ldw r31(,r5),r5
0x7aee0b6c <__pthread_create_system+44>:        ldo 0(r25),r4
0x7aee0b70 <__pthread_create_system+48>:        ldo 0(r24),r6
0x7aee0b74 <__pthread_create_system+52>:        cmpb,= r0,r26,0x7aee0c1c <__pthread_create_system+220>
0x7aee0b78 <__pthread_create_system+56>:        ldo 0(r23),r7
0x7aee0b7c <__pthread_create_system+60>:        cmpb,=,n r0,r6,0x7aee0c1c <__pthread_create_system+220>
0x7aee0b80 <__pthread_create_system+64>:        cmpb,<> r4,r0,0x7aee0bb4 <__pthread_create_system+116>
0x7aee0b84 <__pthread_create_system+68>:        nop
0x7aee0b88 <__pthread_create_system+72>:        ldw -40(,r19),r23
0x7aee0b8c <__pthread_create_system+76>:        ldi 41,r24
0x7aee0b90 <__pthread_create_system+80>:        ldo -90(sp),r31
0x7aee0b94 <__pthread_create_system+84>:        ldw,ma 4(,r23),r20
0x7aee0b98 <__pthread_create_system+88>:        stw,ma r20,4(,r31)
0x7aee0b9c <__pthread_create_system+92>:        ldw,ma 4(,r23),r21
0x7aee0ba0 <__pthread_create_system+96>:        addib,> -8,r24,0x7aee0b94 <__pthread_create_system+84>
0x7aee0ba4 <__pthread_create_system+100>:       stw,ma r21,4(,r31)
0x7aee0ba8 <__pthread_create_system+104>:       ldw 0(,r23),r23
0x7aee0bac <__pthread_create_system+108>:       b,l 0x7aee0c04 <__pthread_create_system+196>,r0
0x7aee0bb0 <__pthread_create_system+112>:       stw r23,0(,r31)
0x7aee0bb4 <__pthread_create_system+116>:       ldw -24(,r19),r26
0x7aee0bb8 <__pthread_create_system+120>:       b,l 0x7aee5dec <__spin_lock>,rp
0x7aee0bbc <__pthread_create_system+124>:       stw r26,-a8(,sp)
0x7aee0bc0 <__pthread_create_system+128>:       ldw -20(,sp),r19
0x7aee0bc4 <__pthread_create_system+132>:       b,l 0x7aee8518 <__pthread_attr_id_lookup>,rp
0x7aee0bc8 <__pthread_create_system+136>:       ldw 0(,r4),r26
0x7aee0bcc <__pthread_create_system+140>:       ldw -20(,sp),r19
0x7aee0bd0 <__pthread_create_system+144>:       cmpb,=,n r0,ret0,0x7aee0c40 <__pthread_create_system+256>
0x7aee0bd4 <__pthread_create_system+148>:       ldi 41,r23
0x7aee0bd8 <__pthread_create_system+152>:       ldo -90(sp),r31
0x7aee0bdc <__pthread_create_system+156>:       ldw,ma 4(,ret0),r24
0x7aee0be0 <__pthread_create_system+160>:       ldw,ma 4(,ret0),r25
0x7aee0be4 <__pthread_create_system+164>:       stw,ma r24,4(,r31)
0x7aee0be8 <__pthread_create_system+168>:       addib,> -8,r23,0x7aee0bdc <__pthread_create_system+156>
0x7aee0bec <__pthread_create_system+172>:       stw,ma r25,4(,r31)
0x7aee0bf0 <__pthread_create_system+176>:       ldw 0(,ret0),r1
0x7aee0bf4 <__pthread_create_system+180>:       stw r1,0(,r31)
0x7aee0bf8 <__pthread_create_system+184>:       b,l 0x7aee5fa8 <__spin_unlock>,rp
0x7aee0bfc <__pthread_create_system+188>:       ldw -a8(,sp),r26
0x7aee0c00 <__pthread_create_system+192>:       ldw -20(,sp),r19
0x7aee0c04 <__pthread_create_system+196>:       b,l 0x7aee0464 <__pthread_id_lookup+84>,rp
0x7aee0c08 <__pthread_create_system+200>:       ldo -90(sp),r26
0x7aee0c0c <__pthread_create_system+204>:       ldw -20(,sp),r19
0x7aee0c10 <__pthread_create_system+208>:       cmpb,<> ret0,r0,0x7aee0c54 <__pthread_create_system+276>
0x7aee0c14 <__pthread_create_system+212>:       ldo 0(ret0),r4
0x7aee0c18 <__pthread_create_system+216>:       depwi,z,tr b,31,32,r3
0x7aee0c1c <__pthread_create_system+220>:       ldi 16,r3
0x7aee0c20 <__pthread_create_system+224>:       ldo 0(r3),ret0
0x7aee0c24 <__pthread_create_system+228>:       ldw -d4(,sp),rp
0x7aee0c28 <__pthread_create_system+232>:       ldw -b0(,sp),r7
0x7aee0c2c <__pthread_create_system+236>:       ldw -b4(,sp),r6
0x7aee0c30 <__pthread_create_system+240>:       ldw -b8(,sp),r5
0x7aee0c34 <__pthread_create_system+244>:       ldw -bc(,sp),r4
0x7aee0c38 <__pthread_create_system+248>:       bv r0(rp)
0x7aee0c3c <__pthread_create_system+252>:       ldw,mb -c0(,sp),r3
0x7aee0c40 <__pthread_create_system+256>:       b,l 0x7aee5fa8 <__spin_unlock>,rp
0x7aee0c44 <__pthread_create_system+260>:       ldw -a8(,sp),r26
0x7aee0c48 <__pthread_create_system+264>:       ldw -20(,sp),r19
0x7aee0c4c <__pthread_create_system+268>:       b,l 0x7aee0c20 <__pthread_create_system+224>,r0
0x7aee0c50 <__pthread_create_system+272>:       ldi 16,r3
0x7aee0c54 <__pthread_create_system+276>:       b,l 0x7aee2234 <__vp_alloc>,rp
0x7aee0c58 <__pthread_create_system+280>:       nop
0x7aee0c5c <__pthread_create_system+284>:       ldw -20(,sp),r19
0x7aee0c60 <__pthread_create_system+288>:       cmpb,<> ret0,r0,0x7aee0c88 <__pthread_create_system+328>
0x7aee0c64 <__pthread_create_system+292>:       nop
0x7aee0c68 <__pthread_create_system+296>:       b,l 0x7aee5dec <__spin_lock>,rp
0x7aee0c6c <__pthread_create_system+300>:       ldo 14(r4),r26
0x7aee0c70 <__pthread_create_system+304>:       ldw -20(,sp),r19
0x7aee0c74 <__pthread_create_system+308>:       b,l 0x7aee074c <__pthread_free>,rp
0x7aee0c78 <__pthread_create_system+312>:       ldo 0(r4),r26
0x7aee0c7c <__pthread_create_system+316>:       ldw -20(,sp),r19
0x7aee0c80 <__pthread_create_system+320>:       movib,tr b,r3,0x7aee0c24 <__pthread_create_system+228>
0x7aee0c84 <__pthread_create_system+324>:       ldo 0(r3),ret0
0x7aee0c88 <__pthread_create_system+328>:       stw r4,8(,ret0)
0x7aee0c8c <__pthread_create_system+332>:       ldw 8(,r4),r31
0x7aee0c90 <__pthread_create_system+336>:       depwi -1,30,1,r31
0x7aee0c94 <__pthread_create_system+340>:       depwi 0,31,1,r31
0x7aee0c98 <__pthread_create_system+344>:       stw r31,8(,r4)
0x7aee0c9c <__pthread_create_system+348>:       depwi -1,31,1,r31
0x7aee0ca0 <__pthread_create_system+352>:       ldw 64(,r4),rp
0x7aee0ca4 <__pthread_create_system+356>:       stw ret0,10(,r4)
0x7aee0ca8 <__pthread_create_system+360>:       ldw -80(,sp),r22
0x7aee0cac <__pthread_create_system+364>:       cmpiclr,<> de,r22,r0
0x7aee0cb0 <__pthread_create_system+368>:       stw r31,8(,r4)
0x7aee0cb4 <__pthread_create_system+372>:       ldb 5c(,r4),r22
0x7aee0cb8 <__pthread_create_system+376>:       depw r0,25,1,r22
0x7aee0cbc <__pthread_create_system+380>:       extrw,u r22,31,8,r21
0x7aee0cc0 <__pthread_create_system+384>:       stw r0,60(,r4)
0x7aee0cc4 <__pthread_create_system+388>:       depwi -1,24,1,r21
0x7aee0cc8 <__pthread_create_system+392>:       extrw,u r21,31,8,r31
0x7aee0ccc <__pthread_create_system+396>:       depw r0,26,1,r31
0x7aee0cd0 <__pthread_create_system+400>:       stb r31,5c(,r4)
0x7aee0cd4 <__pthread_create_system+404>:       stw r0,0(,rp)
0x7aee0cd8 <__pthread_create_system+408>:       stw r6,38(,r4)
0x7aee0cdc <__pthread_create_system+412>:       stw r7,3c(,r4)
0x7aee0ce0 <__pthread_create_system+416>:       ldw -54(,sp),r31
0x7aee0ce4 <__pthread_create_system+420>:       cmpib,<> -3,r31,0x7aee0d08 <__pthread_create_system+456>
0x7aee0ce8 <__pthread_create_system+424>:       nop
0x7aee0cec <__pthread_create_system+428>:       ldw c8(,r5),r25
0x7aee0cf0 <__pthread_create_system+432>:       stw r25,c8(,r4)
0x7aee0cf4 <__pthread_create_system+436>:       ldw cc(,r5),r26
0x7aee0cf8 <__pthread_create_system+440>:       stw r26,cc(,r4)
0x7aee0cfc <__pthread_create_system+444>:       ldw 70(,r5),r26
0x7aee0d00 <__pthread_create_system+448>:       b,l 0x7aee0d28 <__pthread_create_system+488>,r0
0x7aee0d04 <__pthread_create_system+452>:       ldw 74(,r5),r25
0x7aee0d08 <__pthread_create_system+456>:       stw r31,c8(,r4)
0x7aee0d0c <__pthread_create_system+460>:       ldw 8(,r4),r24
0x7aee0d10 <__pthread_create_system+464>:       depwi -1,24,1,r24
0x7aee0d14 <__pthread_create_system+468>:       ldw -50(,sp),ret0
0x7aee0d18 <__pthread_create_system+472>:       stw ret0,cc(,r4)
0x7aee0d1c <__pthread_create_system+476>:       stw r24,8(,r4)
0x7aee0d20 <__pthread_create_system+480>:       ldw 70(,r5),r26
0x7aee0d24 <__pthread_create_system+484>:       ldw 74(,r5),r25
0x7aee0d28 <__pthread_create_system+488>:       stw r26,70(,r4)
0x7aee0d2c <__pthread_create_system+492>:       ldw 78(,r5),r26
0x7aee0d30 <__pthread_create_system+496>:       stw r25,74(,r4)
0x7aee0d34 <__pthread_create_system+500>:       ldw 7c(,r5),ret1
0x7aee0d38 <__pthread_create_system+504>:       stw r26,78(,r4)
0x7aee0d3c <__pthread_create_system+508>:       ldw 80(,r5),r20
0x7aee0d40 <__pthread_create_system+512>:       stw ret1,7c(,r4)
0x7aee0d44 <__pthread_create_system+516>:       ldw 84(,r5),r21
0x7aee0d48 <__pthread_create_system+520>:       stw r20,80(,r4)
0x7aee0d4c <__pthread_create_system+524>:       ldw 88(,r5),r22
0x7aee0d50 <__pthread_create_system+528>:       stw r21,84(,r4)
0x7aee0d54 <__pthread_create_system+532>:       ldw 8c(,r5),ret1
0x7aee0d58 <__pthread_create_system+536>:       stw r22,88(,r4)
0x7aee0d5c <__pthread_create_system+540>:       stw ret1,8c(,r4)
0x7aee0d60 <__pthread_create_system+544>:       ldw -7c(,sp),r23
0x7aee0d64 <__pthread_create_system+548>:       bb,>= r23,1b,0x7aee0db8 <__pthread_create_system+632>
0x7aee0d68 <__pthread_create_system+552>:       nop
0x7aee0d6c <__pthread_create_system+556>:       ldw a4(,r5),ret1
0x7aee0d70 <__pthread_create_system+560>:       stw ret1,a4(,r4)
0x7aee0d74 <__pthread_create_system+564>:       ldw a8(,r5),r20
0x7aee0d78 <__pthread_create_system+568>:       ldw ac(,r5),ret0
0x7aee0d7c <__pthread_create_system+572>:       stw r20,a8(,r4)
0x7aee0d80 <__pthread_create_system+576>:       ldw b0(,r5),r1
0x7aee0d84 <__pthread_create_system+580>:       stw ret0,ac(,r4)
0x7aee0d88 <__pthread_create_system+584>:       ldw b4(,r5),rp
0x7aee0d8c <__pthread_create_system+588>:       stw r1,b0(,r4)
0x7aee0d90 <__pthread_create_system+592>:       ldw b8(,r5),r6
0x7aee0d94 <__pthread_create_system+596>:       stw rp,b4(,r4)
0x7aee0d98 <__pthread_create_system+600>:       ldw bc(,r5),r7
0x7aee0d9c <__pthread_create_system+604>:       stw r6,b8(,r4)
0x7aee0da0 <__pthread_create_system+608>:       ldw c0(,r5),r31
0x7aee0da4 <__pthread_create_system+612>:       stw r7,bc(,r4)
0x7aee0da8 <__pthread_create_system+616>:       ldw c4(,r5),r21
0x7aee0dac <__pthread_create_system+620>:       stw r31,c0(,r4)
0x7aee0db0 <__pthread_create_system+624>:       b,l 0x7aee0e0c <__pthread_create_system+716>,r0
0x7aee0db4 <__pthread_create_system+628>:       stw r21,c4(,r4)
0x7aee0db8 <__pthread_create_system+632>:       ldw -78(,sp),r24
0x7aee0dbc <__pthread_create_system+636>:       stw r24,a4(,r4)
0x7aee0dc0 <__pthread_create_system+640>:       ldw -74(,sp),r22
0x7aee0dc4 <__pthread_create_system+644>:       ldw -70(,sp),r23
0x7aee0dc8 <__pthread_create_system+648>:       stw r22,a8(,r4)
0x7aee0dcc <__pthread_create_system+652>:       ldw -6c(,sp),r24
0x7aee0dd0 <__pthread_create_system+656>:       stw r23,ac(,r4)
0x7aee0dd4 <__pthread_create_system+660>:       ldw -68(,sp),r25
0x7aee0dd8 <__pthread_create_system+664>:       stw r24,b0(,r4)
0x7aee0ddc <__pthread_create_system+668>:       ldw -64(,sp),r26
0x7aee0de0 <__pthread_create_system+672>:       stw r25,b4(,r4)
0x7aee0de4 <__pthread_create_system+676>:       ldw -60(,sp),ret1
0x7aee0de8 <__pthread_create_system+680>:       stw r26,b8(,r4)
0x7aee0dec <__pthread_create_system+684>:       ldw -5c(,sp),r1
0x7aee0df0 <__pthread_create_system+688>:       stw ret1,bc(,r4)
0x7aee0df4 <__pthread_create_system+692>:       ldw 8(,r4),r24
0x7aee0df8 <__pthread_create_system+696>:       depwi -1,25,1,r24
0x7aee0dfc <__pthread_create_system+700>:       ldw -58(,sp),r20
0x7aee0e00 <__pthread_create_system+704>:       stw r1,c0(,r4)
0x7aee0e04 <__pthread_create_system+708>:       stw r20,c4(,r4)
0x7aee0e08 <__pthread_create_system+712>:       stw r24,8(,r4)
0x7aee0e0c <__pthread_create_system+716>:       ldw -4(,r19),r26
0x7aee0e10 <__pthread_create_system+720>:       stw r26,-a4(,sp)
0x7aee0e14 <__pthread_create_system+724>:       ldi 1,r6
0x7aee0e18 <__pthread_create_system+728>:       ldi 1,r7
0x7aee0e1c <__pthread_create_system+732>:       b,l 0x7aee5dec <__spin_lock>,rp
0x7aee0e20 <__pthread_create_system+736>:       stw r6,c(,r4)
0x7aee0e24 <__pthread_create_system+740>:       ldw -20(,sp),r19
0x7aee0e28 <__pthread_create_system+744>:       stw r7,a0(,r4)
0x7aee0e2c <__pthread_create_system+748>:       b,l 0x7aee02a0 <__libc_reinit+364>,rp
0x7aee0e30 <__pthread_create_system+752>:       ldo 0(r4),r26
0x7aee0e34 <__pthread_create_system+756>:       ldw -20(,sp),r19
0x7aee0e38 <__pthread_create_system+760>:       stw ret0,0(,r3)
0x7aee0e3c <__pthread_create_system+764>:       ldw 94(,r5),r31
0x7aee0e40 <__pthread_create_system+768>:       ldo 0(r4),r26
0x7aee0e44 <__pthread_create_system+772>:       b,l 0x7aee014c <__libc_reinit+24>,rp
0x7aee0e48 <__pthread_create_system+776>:       stw r31,98(,r4)
0x7aee0e4c <__pthread_create_system+780>:       ldw -20(,sp),r19
0x7aee0e50 <__pthread_create_system+784>:       ldw -10(,r19),r23
0x7aee0e54 <__pthread_create_system+788>:       stw r23,0(,r4)
0x7aee0e58 <__pthread_create_system+792>:       ldw 4(,r23),rp
0x7aee0e5c <__pthread_create_system+796>:       stw rp,4(,r4)
0x7aee0e60 <__pthread_create_system+800>:       ldw 4(,r23),r1
0x7aee0e64 <__pthread_create_system+804>:       stw r4,0(,r1)
0x7aee0e68 <__pthread_create_system+808>:       stw r4,4(,r23)
0x7aee0e6c <__pthread_create_system+812>:       ldw -18(,r19),r3
0x7aee0e70 <__pthread_create_system+816>:       ldw 0(,r3),ret0
0x7aee0e74 <__pthread_create_system+820>:       ldw 20(,r19),ret1
0x7aee0e78 <__pthread_create_system+824>:       ldo 1(ret0),rp
0x7aee0e7c <__pthread_create_system+828>:       stw rp,0(,r3)
0x7aee0e80 <__pthread_create_system+832>:       ldw 0(,ret1),r3
0x7aee0e84 <__pthread_create_system+836>:       ldo 1(r3),r5
0x7aee0e88 <__pthread_create_system+840>:       stw r5,0(,ret1)
0x7aee0e8c <__pthread_create_system+844>:       b,l 0x7aee5fa8 <__spin_unlock>,rp
0x7aee0e90 <__pthread_create_system+848>:       ldw -a4(,sp),r26
0x7aee0e94 <__pthread_create_system+852>:       ldw -20(,sp),r19
0x7aee0e98 <__pthread_create_system+856>:       ldw -60(,r19),r20
0x7aee0e9c <__pthread_create_system+860>:       ldi 1,r21
0x7aee0ea0 <__pthread_create_system+864>:       stw r21,0(,r20)
0x7aee0ea4 <__pthread_create_system+868>:       ldo 0(r4),r26
0x7aee0ea8 <__pthread_create_system+872>:       ldw 98(,r19),r22
0x7aee0eac <__pthread_create_system+876>:       b,l 0x7aee2280 <__vp_create>,rp
0x7aee0eb0 <__pthread_create_system+880>:       ldw 0(,r22),r25
0x7aee0eb4 <__pthread_create_system+884>:       ldw -20(,sp),r19
0x7aee0eb8 <__pthread_create_system+888>:       cmpb,= ret0,r0,0x7aee0ee8 <__pthread_create_system+936>
0x7aee0ebc <__pthread_create_system+892>:       ldo 0(ret0),r3
0x7aee0ec0 <__pthread_create_system+896>:       b,l 0x7aee5dec <__spin_lock>,rp
0x7aee0ec4 <__pthread_create_system+900>:       ldo 14(r4),r26
0x7aee0ec8 <__pthread_create_system+904>:       ldw -20(,sp),r19
0x7aee0ecc <__pthread_create_system+908>:       b,l 0x7aee074c <__pthread_free>,rp
0x7aee0ed0 <__pthread_create_system+912>:       ldo 0(r4),r26
0x7aee0ed4 <__pthread_create_system+916>:       ldw -20(,sp),r19
0x7aee0ed8 <__pthread_create_system+920>:       cmpiclr,<> e,r3,r0
0x7aee0edc <__pthread_create_system+924>:       ldi 16,r3
0x7aee0ee0 <__pthread_create_system+928>:       b,l 0x7aee0c24 <__pthread_create_system+228>,r0
0x7aee0ee4 <__pthread_create_system+932>:       ldo 0(r3),ret0
0x7aee0ee8 <__pthread_create_system+936>:       ldo 0(r4),r25
0x7aee0eec <__pthread_create_system+940>:       b,l 0x7aee2104 <_pthread_callback_np+340>,rp
0x7aee0ef0 <__pthread_create_system+944>:       ldi 1,r26
0x7aee0ef4 <__pthread_create_system+948>:       ldw -20(,sp),r19
0x7aee0ef8 <__pthread_create_system+952>:       movb,tr r0,r3,0x7aee0c24 <__pthread_create_system+228>
0x7aee0efc <__pthread_create_system+956>:       ldo 0(r3),ret0
0x7aee0f00 <__pthread_create_system+960>:       b,l 0x7aee0f18 <__pthread_create_system+984>,rp
0x7aee0f04 <__pthread_create_system+964>:       nop
0x7aee0f08 <__pthread_create_system+968>:       ldw -18(,sp),rp
0x7aee0f0c <__pthread_create_system+972>:       ldsid (,rp),r1
0x7aee0f10 <__pthread_create_system+976>:       mtsp r1,sr0
0x7aee0f14 <__pthread_create_system+980>:       be,n 0(sr0,rp)
0x7aee0f18 <__pthread_create_system+984>:       stw rp,-14(,sp)
0x7aee0f1c <__pthread_create_system+988>:       stw,ma r3,40(,sp)
0x7aee0f20 <__pthread_create_system+992>:       ldo 0(r26),r3
0x7aee0f24 <__pthread_create_system+996>:       stw r19,-20(,sp)
0x7aee0f28 <__pthread_create_system+1000>:      ldw 8(,r26),r31
0x7aee0f2c <__pthread_create_system+1004>:      bb,>= r31,f,0x7aee0f40 <__pthread_create_system+1024>
0x7aee0f30 <__pthread_create_system+1008>:      nop
0x7aee0f34 <__pthread_create_system+1012>:      b,l 0x7aee014c <__libc_reinit+24>,rp
0x7aee0f38 <__pthread_create_system+1016>:      ldo 0(r3),r26
0x7aee0f3c <__pthread_create_system+1020>:      ldw -20(,sp),r19
0x7aee0f40 <__pthread_create_system+1024>:      ldi 2,r26
0x7aee0f44 <__pthread_create_system+1028>:      b,l 0x7aee2104 <_pthread_callback_np+340>,rp
0x7aee0f48 <__pthread_create_system+1032>:      ldo 0(r3),r25
0x7aee0f4c <__pthread_create_system+1036>:      ldw -20(,sp),r19
0x7aee0f50 <__pthread_create_system+1040>:      ldw 38(,r3),r22
0x7aee0f54 <__pthread_create_system+1044>:      ldw 3c(,r3),r26
0x7aee0f58 <__pthread_create_system+1048>:      b,l 0x7aedcce4 <$$dyncall_external>,r31
0x7aee0f5c <__pthread_create_system+1052>:      ldo 0(r31),rp
0x7aee0f60 <__pthread_create_system+1056>:      ldw -20(,sp),r19
0x7aee0f64 <__pthread_create_system+1060>:      stw ret0,40(,r3)
0x7aee0f68 <__pthread_create_system+1064>:      b,l 0x7aee1308 <pthread_exit>,rp
0x7aee0f6c <__pthread_create_system+1068>:      ldo 0(ret0),r26
0x7aee0f70 <__pthread_create_system+1072>:      ldw -20(,sp),r19
0x7aee0f74 <__pthread_create_system+1076>:      ldw -54(,sp),rp
0x7aee0f78 <__pthread_create_system+1080>:      bv r0(rp)
0x7aee0f7c <__pthread_create_system+1084>:      ldw,mb -40(,sp),r3

Re: [RFC] Infinite backtraces...

[Randolph Chung]

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

i just found another instance where these stub frames is causing
problems, and this one is not just "cosmetic" ...

suppose you are calling a function through a stub, so your stack frames
are:

#0 callee
#1 callee stub
#2 caller

if you do a "finish" from callee, gdb will stop in the callee stub
instead of at the caller. quite annoying :(

i'm wondering if we should make the hppa unwinders more export-stub
aware -- e.g. in hppa_frame_cache (), after we've determined the address
of the current frame, we can see if this is an "export stub" frame, and
if so automatically rewind one more frame. i think this should work and
shouldn't cause any problems.... thoughts?

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

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

> #0 callee
> #1 callee stub
> #2 caller
> 
> if you do a "finish" from callee, gdb will stop in the callee stub
> instead of at the caller. quite annoying :(

Ah yes, of course. What a bummer.

> i'm wondering if we should make the hppa unwinders more export-stub
> aware -- e.g. in hppa_frame_cache (), after we've determined the address
> of the current frame, we can see if this is an "export stub" frame, and
> if so automatically rewind one more frame. i think this should work and
> shouldn't cause any problems.... thoughts?

I would certainly agree with that.

-- 
Joel

Re: [RFC] Infinite backtraces...

[Andrew Cagney]

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

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

> 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 :-(

That's pretty much what I have done as a proof of concept.
I ran it through the testsuite on our HP machine, and we got
3 new passes (from 3 unresolved, due to the expect buffer filling up).

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

This is of course a good solution, provided that you can use dwarf2.
On 32bit HP/UX, we're stuck.

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

I am not sure this is doable. Is it? Let me check that again. Perhaps
it's ok to create the frame object, but then later compute a null frame
ID for it? As far as I remember, the sequence of events is like this
when trying to build the frame chain:

  . get_prev_frame (this_frame):
      . get_frame_id (this_frame)
          . frame_id (next_frame, this_cache)
      . check this frame ID
      . build previous frame
        (frame ID unset)
 
And then, after building each new frame, we display the information
for that new frame.

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

But could we determine that a symbol is outermost. And couldn't the
same symbol be used in both contexts?

-- 
Joel

Re: [RFC] Infinite backtraces...

[Andrew Cagney]

>>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.
> 
> 
> This is of course a good solution, provided that you can use dwarf2.
> On 32bit HP/UX, we're stuck.

Doh!

>>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.
> 
> 
> I am not sure this is doable. Is it? Let me check that again. Perhaps
> it's ok to create the frame object, but then later compute a null frame
> ID for it? As far as I remember, the sequence of events is like this
> when trying to build the frame chain:
> 
>   . get_prev_frame (this_frame):
>       . get_frame_id (this_frame)
>           . frame_id (next_frame, this_cache)
>       . check this frame ID
>       . build previous frame
>         (frame ID unset)

Yes, gdb already creates the frame object and then later constructs the 
frame ID.  The build has been reduced to:

	prev_frame = malloc ();
	prev_frame->next = this_frame;
	return prev_frame;

Also note that, unlike the past, the frame ID is separate to the ``frame 
base'' the former can be NULL while the later is still valid.

> And then, after building each new frame, we display the information
> for that new frame.

It is what lets us "up" on to an apparently corrupt frame.

>>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.
> 
> 
> But could we determine that a symbol is outermost. And couldn't the
> same symbol be used in both contexts?

Determining that a symbol is outer-most is somewhat osabi dependant - 
the arch dependant code would need to register or mark it up as such.

Yes, the symbol can be used in both contexts vis:

	main (argc) { if (argc > 0) main (argc - 1); }

but I suspect it is illegal.

Andrew

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

> Yes, gdb already creates the frame object and then later constructs the 
> frame ID.  The build has been reduced to:
> 
> 	prev_frame = malloc ();
> 	prev_frame->next = this_frame;
> 	return prev_frame;
> 
> Also note that, unlike the past, the frame ID is separate to the ``frame 
> base'' the former can be NULL while the later is still valid.
> 
> >And then, after building each new frame, we display the information
> >for that new frame.
> 
> It is what lets us "up" on to an apparently corrupt frame.

Reviewing the code that does the backtrace, I don't see how this
would work. We're at the oldest frame, trying to unwind from it.
So we compute its ID, and then create the previous frame.

I didn't find where in our code, in particular in stack.c, we're
prepared to deal with a frame that we later find is invalid (via a null
frame ID). Perhaps it is simpler to modify the build sequence above to
add the computation of the frame ID and use that as a guard before
creating the new frame?

-- 
Joel

Re: [RFC] Infinite backtraces...

[Andrew Cagney]

Joel Brobecker wrote:
>>Yes, gdb already creates the frame object and then later constructs the 
>>frame ID.  The build has been reduced to:
>>
>>	prev_frame = malloc ();
>>	prev_frame->next = this_frame;
>>	return prev_frame;
>>
>>Also note that, unlike the past, the frame ID is separate to the ``frame 
>>base'' the former can be NULL while the later is still valid.
>>
>>
>>>And then, after building each new frame, we display the information
>>>for that new frame.
>>
>>It is what lets us "up" on to an apparently corrupt frame.
> 
> 
> Reviewing the code that does the backtrace, I don't see how this
> would work. We're at the oldest frame, trying to unwind from it.
> So we compute its ID, and then create the previous frame.

Which ID, this or prev?

GDB computes this-ID does some sanity checks and then, assuming it is 
valid, blindly creates prev frame.

> I didn't find where in our code, in particular in stack.c, we're
> prepared to deal with a frame that we later find is invalid (via a null
> frame ID). Perhaps it is simpler to modify the build sequence above to
> add the computation of the frame ID and use that as a guard before
> creating the new frame?

A null-ID indicates that the frame can't be unwound from, not that it is 
necessarially itself invalid.

I think you're describing the old logic:

    if (prev frame ID valid)
	then return prev frame

it had the problem that it wasn't possible to examine that terminal, 
possibly corrupt, frame.  I deleted the test (and there was much 
celebration :-).

There are two objectives here:

- stop a run-away stack
which means correctly determining it's end

- deciding, for possibly cosmetic reasons, which frames to list
which means stopping the list at main by default

when it comes to the true outer-most frame there's always going to be 
fuz, as long as it terminates I think we're ok.

Andrew

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

> >Reviewing the code that does the backtrace, I don't see how this
> >would work. We're at the oldest frame, trying to unwind from it.
> >So we compute its ID, and then create the previous frame.
> 
> Which ID, this or prev?

We create the ID of this frame. Then create the previous frame.

I think I'm starting to see how I was confused.  Going back to my
initial example, we have:

    #0  simple.break_me () at simple.adb:27
    #1  0x0000a2cc in simple.caller (<_task>=0x4001c3a0) at simple.adb:21
    #2  0x0000a268 in simple__callerB___2 () at simple.adb:18
    #3  0x00017184 in system.tasking.stages.task_wrapper ()
    #4  0x00017058 in system__tasking__stages__task_wrapper ()
    #5  0x7aee0f60 in __pthread_create_system () from /usr/lib/libpthread.1
    #6  0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
    #7  0x00000000 in ?? ()

Imagine we are at frame #6, and try to go up one frame. So what happens
is that we compute the ID of frame #6, and then, assuming all the sanity
checks are ok, create frame #7.

What you are suggesting is that we return a null frame ID for frame
#6, correct? What I thought you were saying is that we return a null
frame ID for frame *7*, which of course should never exist.

> A null-ID indicates that the frame can't be unwound from, not that it is 
> necessarially itself invalid.

I think that's the key I didn't understand.

> There are two objectives here:
> 
> - stop a run-away stack
> which means correctly determining it's end

This is the problem we're trying to solve.

> - deciding, for possibly cosmetic reasons, which frames to list
> which means stopping the list at main by default

This part, I think, is fine.

> when it comes to the true outer-most frame there's always going to be
> fuz, as long as it terminates I think we're ok.

Absolutely.

Thanks for the explanation! Hopefully I got it right this time.
-- 
Joel

Re: [RFC] Infinite backtraces...

[Daniel Jacobowitz]

On Fri, Dec 03, 2004 at 01:57:45PM -0800, Joel Brobecker wrote:
> > >Reviewing the code that does the backtrace, I don't see how this
> > >would work. We're at the oldest frame, trying to unwind from it.
> > >So we compute its ID, and then create the previous frame.
> > 
> > Which ID, this or prev?
> 
> We create the ID of this frame. Then create the previous frame.
> 
> I think I'm starting to see how I was confused.  Going back to my
> initial example, we have:
> 
>     #0  simple.break_me () at simple.adb:27
>     #1  0x0000a2cc in simple.caller (<_task>=0x4001c3a0) at simple.adb:21
>     #2  0x0000a268 in simple__callerB___2 () at simple.adb:18
>     #3  0x00017184 in system.tasking.stages.task_wrapper ()
>     #4  0x00017058 in system__tasking__stages__task_wrapper ()
>     #5  0x7aee0f60 in __pthread_create_system () from /usr/lib/libpthread.1
>     #6  0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
>     #7  0x00000000 in ?? ()
> 
> Imagine we are at frame #6, and try to go up one frame. So what happens
> is that we compute the ID of frame #6, and then, assuming all the sanity
> checks are ok, create frame #7.
> 
> What you are suggesting is that we return a null frame ID for frame
> #6, correct? What I thought you were saying is that we return a null
> frame ID for frame *7*, which of course should never exist.

I'd suggest that you return a null frame ID from frame *5* actually.
Is there a reason not to do that?  Certainly a bit of caution is called
for, but if GDB has the knowledge that a particular bit of code can
never be backtraced through...

There's an equivalent function in the glibc thread libraries 
for starting a thread, which should never be backtraced through.  Note
that we can't do a similar thing for clone unless the target's library
provides a symbol distinct from clone to use; we have to be able to
backtrace from clone itself.

-- 
Daniel Jacobowitz

Re: [RFC] Infinite backtraces...

[Joel Brobecker]

> >     #0  simple.break_me () at simple.adb:27
> >     #1  0x0000a2cc in simple.caller (<_task>=0x4001c3a0) at simple.adb:21
> >     #2  0x0000a268 in simple__callerB___2 () at simple.adb:18
> >     #3  0x00017184 in system.tasking.stages.task_wrapper ()
> >     #4  0x00017058 in system__tasking__stages__task_wrapper ()
> >     #5  0x7aee0f60 in __pthread_create_system () from /usr/lib/libpthread.1
> >     #6  0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
> >     #7  0x00000000 in ?? ()
> > 
> > Imagine we are at frame #6, and try to go up one frame. So what happens
> > is that we compute the ID of frame #6, and then, assuming all the sanity
> > checks are ok, create frame #7.
> > 
> > What you are suggesting is that we return a null frame ID for frame
> > #6, correct? What I thought you were saying is that we return a null
> > frame ID for frame *7*, which of course should never exist.
> 
> I'd suggest that you return a null frame ID from frame *5* actually.
> Is there a reason not to do that?  Certainly a bit of caution is called
> for, but if GDB has the knowledge that a particular bit of code can
> never be backtraced through...

Do you mean by checking the procedure name against "__pthread_create_system"?
This should certainly be very easy to do. This is, on the other hand,
OS specific. So this check should only be made when the OS is HPUX.

-- 
Joel