This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Making "info thread" sane
- From: George Anzinger <george at mvista dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, Eli Zaretskii <eliz at elta dot co dot il>, gdb at sources dot redhat dot com
- Date: Tue, 20 Apr 2004 17:44:37 -0700
- Subject: Re: Making "info thread" sane
- Organization: MontaVista Software
- References: <403FEA02.6040506@mvista.com> <200403011454.35346.amitkale@emsyssoft.com> <4044FEDE.5000105@mvista.com> <20040302214535.GA24405@nevyn.them.org> <40450749.7020304@mvista.com> <20040302221718.GA26931@nevyn.them.org> <404515AA.8040709@mvista.com> <404517E8.1020708@gnu.org> <4045236B.3060104@mvista.com> <uptbuo4dl.fsf@elta.co.il> <20040303142842.GA12777@nevyn.them.org> <4046267E.1080808@mvista.com> <404629E3.5020906@gnu.org> <40465651.900@mvista.com> <404D1CFF.6070209@gnu.org> <40510325.4070101@mvista.com> <40522C95.7060900@gnu.org>
- Reply-to: ganzinger at mvista dot com
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 george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml