Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: George Anzinger <george@mvista.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: Daniel Jacobowitz <drow@mvista.com>,
	Eli Zaretskii <eliz@elta.co.il>,
	gdb@sources.redhat.com
Subject: Re: Making "info thread" sane
Date: Wed, 21 Apr 2004 01:30:00 -0000	[thread overview]
Message-ID: <4085C3F5.6030408@mvista.com> (raw)
In-Reply-To: <40522C95.7060900@gnu.org>

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


  parent reply	other threads:[~2004-04-21  0:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040227212301.GC1052@smtp.west.cox.net>
     [not found] ` <20040227235059.GG425@elf.ucw.cz>
     [not found]   ` <403FEA02.6040506@mvista.com>
     [not found]     ` <200403011454.35346.amitkale@emsyssoft.com>
     [not found]       ` <4044FEDE.5000105@mvista.com>
     [not found]         ` <20040302214535.GA24405@nevyn.them.org>
     [not found]           ` <40450749.7020304@mvista.com>
     [not found]             ` <20040302221718.GA26931@nevyn.them.org>
2004-03-02 23:15               ` George Anzinger
2004-03-02 23:25                 ` Andrew Cagney
2004-03-03  0:14                   ` George Anzinger
2004-03-03  6:01                     ` Eli Zaretskii
2004-03-03 14:28                       ` Daniel Jacobowitz
2004-03-03 15:08                         ` Andrew Cagney
2004-03-03 18:40                         ` George Anzinger
2004-03-03 18:54                           ` Andrew Cagney
2004-03-03 22:04                             ` George Anzinger
2004-03-09  1:25                               ` Andrew Cagney
2004-03-12  0:24                                 ` George Anzinger
2004-03-12 21:33                                   ` Andrew Cagney
2004-03-22  9:40                                     ` George Anzinger
2004-04-21  1:30                                     ` George Anzinger [this message]
2004-03-08 19:21 Jim Houston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4085C3F5.6030408@mvista.com \
    --to=george@mvista.com \
    --cc=cagney@gnu.org \
    --cc=drow@mvista.com \
    --cc=eliz@elta.co.il \
    --cc=ganzinger@mvista.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox