* [RFC] Infinite backtraces...
@ 2004-12-02 22:46 Joel Brobecker
2004-12-02 23:13 ` Joel Brobecker
2004-12-03 18:28 ` Andrew Cagney
0 siblings, 2 replies; 27+ messages in thread
From: Joel Brobecker @ 2004-12-02 22:46 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
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;
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-02 22:46 [RFC] Infinite backtraces Joel Brobecker
@ 2004-12-02 23:13 ` Joel Brobecker
2004-12-03 2:43 ` Randolph Chung
2004-12-03 18:28 ` Andrew Cagney
1 sibling, 1 reply; 27+ messages in thread
From: Joel Brobecker @ 2004-12-02 23:13 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-02 23:13 ` Joel Brobecker
@ 2004-12-03 2:43 ` Randolph Chung
2004-12-03 2:57 ` Joel Brobecker
0 siblings, 1 reply; 27+ messages in thread
From: Randolph Chung @ 2004-12-03 2:43 UTC (permalink / raw)
To: gdb-patches; +Cc: brobecker
> 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/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 2:43 ` Randolph Chung
@ 2004-12-03 2:57 ` Joel Brobecker
2004-12-03 4:53 ` Randolph Chung
0 siblings, 1 reply; 27+ messages in thread
From: Joel Brobecker @ 2004-12-03 2:57 UTC (permalink / raw)
To: Randolph Chung; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 2:57 ` Joel Brobecker
@ 2004-12-03 4:53 ` Randolph Chung
2004-12-03 19:36 ` Joel Brobecker
0 siblings, 1 reply; 27+ messages in thread
From: Randolph Chung @ 2004-12-03 4:53 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
> 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/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 19:36 ` Joel Brobecker
@ 2004-12-03 18:03 ` Randolph Chung
2004-12-03 18:20 ` Joel Brobecker
2004-12-03 18:22 ` Joel Brobecker
2004-12-06 4:15 ` Randolph Chung
2 siblings, 1 reply; 27+ messages in thread
From: Randolph Chung @ 2004-12-03 18:03 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
> > 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;
}
}
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 18:03 ` Randolph Chung
@ 2004-12-03 18:20 ` Joel Brobecker
2004-12-03 18:22 ` Randolph Chung
2004-12-06 7:25 ` Randolph Chung
0 siblings, 2 replies; 27+ messages in thread
From: Joel Brobecker @ 2004-12-03 18:20 UTC (permalink / raw)
To: Randolph Chung; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 19:36 ` Joel Brobecker
2004-12-03 18:03 ` Randolph Chung
@ 2004-12-03 18:22 ` Joel Brobecker
2004-12-06 4:15 ` Randolph Chung
2 siblings, 0 replies; 27+ messages in thread
From: Joel Brobecker @ 2004-12-03 18:22 UTC (permalink / raw)
To: Randolph Chung; +Cc: gdb-patches
[-- 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 18:20 ` Joel Brobecker
@ 2004-12-03 18:22 ` Randolph Chung
2004-12-06 7:25 ` Randolph Chung
1 sibling, 0 replies; 27+ messages in thread
From: Randolph Chung @ 2004-12-03 18:22 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
> 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/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-02 22:46 [RFC] Infinite backtraces Joel Brobecker
2004-12-02 23:13 ` Joel Brobecker
@ 2004-12-03 18:28 ` Andrew Cagney
2004-12-03 18:49 ` Joel Brobecker
1 sibling, 1 reply; 27+ messages in thread
From: Andrew Cagney @ 2004-12-03 18:28 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 18:28 ` Andrew Cagney
@ 2004-12-03 18:49 ` Joel Brobecker
2004-12-03 19:26 ` Andrew Cagney
0 siblings, 1 reply; 27+ messages in thread
From: Joel Brobecker @ 2004-12-03 18:49 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 18:49 ` Joel Brobecker
@ 2004-12-03 19:26 ` Andrew Cagney
2004-12-03 20:19 ` Joel Brobecker
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Cagney @ 2004-12-03 19:26 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
>>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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 4:53 ` Randolph Chung
@ 2004-12-03 19:36 ` Joel Brobecker
2004-12-03 18:03 ` Randolph Chung
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Joel Brobecker @ 2004-12-03 19:36 UTC (permalink / raw)
To: Randolph Chung; +Cc: gdb-patches
[-- 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 19:26 ` Andrew Cagney
@ 2004-12-03 20:19 ` Joel Brobecker
2004-12-03 21:44 ` Andrew Cagney
0 siblings, 1 reply; 27+ messages in thread
From: Joel Brobecker @ 2004-12-03 20:19 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 20:19 ` Joel Brobecker
@ 2004-12-03 21:44 ` Andrew Cagney
2004-12-03 22:16 ` Joel Brobecker
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Cagney @ 2004-12-03 21:44 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 21:44 ` Andrew Cagney
@ 2004-12-03 22:16 ` Joel Brobecker
2004-12-03 22:23 ` Daniel Jacobowitz
0 siblings, 1 reply; 27+ messages in thread
From: Joel Brobecker @ 2004-12-03 22:16 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
> >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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 22:16 ` Joel Brobecker
@ 2004-12-03 22:23 ` Daniel Jacobowitz
2004-12-03 22:25 ` Joel Brobecker
0 siblings, 1 reply; 27+ messages in thread
From: Daniel Jacobowitz @ 2004-12-03 22:23 UTC (permalink / raw)
To: Joel Brobecker; +Cc: Andrew Cagney, gdb-patches
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 22:23 ` Daniel Jacobowitz
@ 2004-12-03 22:25 ` Joel Brobecker
0 siblings, 0 replies; 27+ messages in thread
From: Joel Brobecker @ 2004-12-03 22:25 UTC (permalink / raw)
To: Andrew Cagney, gdb-patches
> > #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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 19:36 ` Joel Brobecker
2004-12-03 18:03 ` Randolph Chung
2004-12-03 18:22 ` Joel Brobecker
@ 2004-12-06 4:15 ` Randolph Chung
2004-12-07 9:40 ` Joel Brobecker
2 siblings, 1 reply; 27+ messages in thread
From: Randolph Chung @ 2004-12-06 4:15 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
> 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/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-03 18:20 ` Joel Brobecker
2004-12-03 18:22 ` Randolph Chung
@ 2004-12-06 7:25 ` Randolph Chung
2004-12-07 10:07 ` Joel Brobecker
1 sibling, 1 reply; 27+ messages in thread
From: Randolph Chung @ 2004-12-06 7:25 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
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 = {
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-06 4:15 ` Randolph Chung
@ 2004-12-07 9:40 ` Joel Brobecker
0 siblings, 0 replies; 27+ messages in thread
From: Joel Brobecker @ 2004-12-07 9:40 UTC (permalink / raw)
To: Randolph Chung; +Cc: gdb-patches
> #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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-06 7:25 ` Randolph Chung
@ 2004-12-07 10:07 ` Joel Brobecker
2004-12-07 16:31 ` Randolph Chung
0 siblings, 1 reply; 27+ messages in thread
From: Joel Brobecker @ 2004-12-07 10:07 UTC (permalink / raw)
To: Randolph Chung; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-07 10:07 ` Joel Brobecker
@ 2004-12-07 16:31 ` Randolph Chung
2004-12-07 16:37 ` Joel Brobecker
0 siblings, 1 reply; 27+ messages in thread
From: Randolph Chung @ 2004-12-07 16:31 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
> 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/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-07 16:31 ` Randolph Chung
@ 2004-12-07 16:37 ` Joel Brobecker
2004-12-07 16:52 ` Randolph Chung
2004-12-08 1:51 ` Randolph Chung
0 siblings, 2 replies; 27+ messages in thread
From: Joel Brobecker @ 2004-12-07 16:37 UTC (permalink / raw)
To: Randolph Chung; +Cc: gdb-patches
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-07 16:37 ` Joel Brobecker
@ 2004-12-07 16:52 ` Randolph Chung
2004-12-08 1:51 ` Randolph Chung
1 sibling, 0 replies; 27+ messages in thread
From: Randolph Chung @ 2004-12-07 16:52 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
> 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/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFC] Infinite backtraces...
2004-12-07 16:37 ` Joel Brobecker
2004-12-07 16:52 ` Randolph Chung
@ 2004-12-08 1:51 ` Randolph Chung
2004-12-12 16:36 ` [commit] Move zero PC check to frame.c; Was: " Andrew Cagney
1 sibling, 1 reply; 27+ messages in thread
From: Randolph Chung @ 2004-12-08 1:51 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
> 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 = {
^ permalink raw reply [flat|nested] 27+ messages in thread
* [commit] Move zero PC check to frame.c; Was: [RFC] Infinite backtraces...
2004-12-08 1:51 ` Randolph Chung
@ 2004-12-12 16:36 ` Andrew Cagney
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Cagney @ 2004-12-12 16:36 UTC (permalink / raw)
To: Randolph Chung; +Cc: Joel Brobecker, gdb-patches
[-- 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);
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2004-12-12 16:27 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-02 22:46 [RFC] Infinite backtraces Joel Brobecker
2004-12-02 23:13 ` Joel Brobecker
2004-12-03 2:43 ` Randolph Chung
2004-12-03 2:57 ` Joel Brobecker
2004-12-03 4:53 ` Randolph Chung
2004-12-03 19:36 ` Joel Brobecker
2004-12-03 18:03 ` Randolph Chung
2004-12-03 18:20 ` Joel Brobecker
2004-12-03 18:22 ` Randolph Chung
2004-12-06 7:25 ` Randolph Chung
2004-12-07 10:07 ` Joel Brobecker
2004-12-07 16:31 ` Randolph Chung
2004-12-07 16:37 ` Joel Brobecker
2004-12-07 16:52 ` Randolph Chung
2004-12-08 1:51 ` Randolph Chung
2004-12-12 16:36 ` [commit] Move zero PC check to frame.c; Was: " Andrew Cagney
2004-12-03 18:22 ` Joel Brobecker
2004-12-06 4:15 ` Randolph Chung
2004-12-07 9:40 ` Joel Brobecker
2004-12-03 18:28 ` Andrew Cagney
2004-12-03 18:49 ` Joel Brobecker
2004-12-03 19:26 ` Andrew Cagney
2004-12-03 20:19 ` Joel Brobecker
2004-12-03 21:44 ` Andrew Cagney
2004-12-03 22:16 ` Joel Brobecker
2004-12-03 22:23 ` Daniel Jacobowitz
2004-12-03 22:25 ` Joel Brobecker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox