From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31785 invoked by alias); 21 Apr 2004 00:44:49 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31502 invoked from network); 21 Apr 2004 00:44:45 -0000 Received: from unknown (HELO av.mvista.com) (12.44.186.158) by sources.redhat.com with SMTP; 21 Apr 2004 00:44:45 -0000 Received: from data.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id RAA29051; Tue, 20 Apr 2004 17:44:41 -0700 Received: from mvista.com (localhost [127.0.0.1]) by data.mvista.com (8.12.8/8.12.8) with ESMTP id i3L0ibjv021783; Tue, 20 Apr 2004 17:44:38 -0700 Message-ID: <4085C3F5.6030408@mvista.com> Date: Wed, 21 Apr 2004 01:30:00 -0000 From: George Anzinger Reply-To: ganzinger@mvista.com Organization: MontaVista Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 MIME-Version: 1.0 To: Andrew Cagney CC: Daniel Jacobowitz , Eli Zaretskii , gdb@sources.redhat.com Subject: Re: Making "info thread" sane 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> <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> In-Reply-To: <40522C95.7060900@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00115.txt.bz2 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