Making "info thread" sane

George Anzinger
Wed Apr 21 01:30:00 GMT 2004

Some time ago I started working on dwarf code for the linux kernel to allow gdb 
(via kgdb) to back trace through interrupts and traps.  The main problem here is 
that the back trace needs to terminate if the trap or interrupt comes from user 
space.  If it came from the kernel we want to keep on trucking.

At one time, the indication in gdb that the stack was exhausted was getting back 
a P register of 0.  Someone (don't know who) said "NOWAY", and, as I recall, gdb 
was changed to no longer do this.  The alternative proposed was to return a 
frame address of zero.

I would like to question this.  There are two problems here:

1) With a frame address of zero, none of the other registers are available to 
gdb (since they would be at location 0 or there about).  While we may be at the 
BOS, it is still possible to have meaningful register content.

2) In order to do the dwarf CFA / FDE for these frames an expression needs to be 
used.  If we use an expression for the CFA address, each FDE needs to have this 
expression, while if we use an expression for the P register, only the CFI need 
have the expression.  In the x86 entry.S code, traps will usually have a couple 
of additional things pushed on the stack prior to the call.  These are popped 
when the call returns, but the FDE for these frames, rather than being a simple 
relocation of the CFA has to do the whole expression thing.

As to using a P register of 0, as gdb currently stands, it always subtracts 1 
from the P register (which is typed as an unsigned long).  This means that it 
will be using 0xffffffff to look for a frame.  On all the machines I am aware 
of, this is a violation of the address space constraints, i.e. 0xffffffff is 
NEVER going to be in the same space as 0 and no valid frame will ever be found 
with this address.

I would like to change gdb to recognize P = 0 as a special case which indicated 
that there is no further unwind information.
George Anzinger
Preemption patch:

More information about the Gdb mailing list