From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2364 invoked by alias); 10 Mar 2004 03:05:32 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2323 invoked from network); 10 Mar 2004 03:05:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 10 Mar 2004 03:05:31 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B0u2D-0004Fl-0t; Tue, 09 Mar 2004 22:05:29 -0500 Date: Wed, 10 Mar 2004 03:05:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com, vinschen@redhat.com Subject: Re: [RFC/RFA] gdb.cp/classes.exp: Don't try to print local variable out of scope Message-ID: <20040310030528.GB16230@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michael Elizabeth Chastain , gdb-patches@sources.redhat.com, vinschen@redhat.com References: <20040309161507.9FBF54B104@berman.michael-chastain.com> <404E2B2C.8030201@gnu.org> <20040309212736.GA8404@nevyn.them.org> <404E45EC.4030205@gnu.org> <20040310005631.GA13440@nevyn.them.org> <404E7489.4010209@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404E7489.4010209@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03.o/txt/msg00223.txt On Tue, Mar 09, 2004 at 08:51:05PM -0500, Andrew Cagney wrote: > > >BTW, I think the NORMAL_FRAME check is wrong too: > > > > { > > int i; > > stuff (i); > >-> } > > > >get signal > > Er, hold on. The intent of address-in-block is: > > /* An address (not necessarily alligned to an instruction boundary) > that falls within THIS frame's code block. > > When a function call is the last statement in a block, the return > address for the call may land at the start of the next block. > Similarly, if a no-return function call is the last statement in > the function, the return address may end up pointing beyond the > function, and possibly at the start of the next function. > The only way to get a PC pointing at the first instruction of a function > is for that function to have been interrupted just as that first > instruction was about to be executed -- thats the very case where the > existing address_in_block correctly leaves the PC as is. > > In the example in question: > > > > > { > > int i; > > stuff (i); > > -> } > > the existing code correctly puts the PC at the instruction about to > destroy the prologue. Think about this for a moment. I'm going to give addresses so that I can be more precise. 0x10 : ret stuff(int) { } 0x20
: push main() { 0x21 : push { 0x22 : move arg1, i stuff(i) 0x23 : call stuff " 0x24 : pop } 0x25 : pop } 0x26 : ret " The inner scope is probably to inclusive. Suppose PC == 0x10. We backtrace. Look at main; saved PC is 0x24. We want an address in the block. We subtract 1. OK, saved addr-in-block is 0x23. 'i' is in scope. Suppose PC == 0x24. Shouldn't this be the same? For the purposes of looking at local variables, aren't we still in the the block? Suppose PC was 0x24 and we got a signal. Ditto. Suppose PC == 0x20 and we get a signal. Obviously we don't want to change the behavior of this. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2364 invoked by alias); 10 Mar 2004 03:05:32 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2323 invoked from network); 10 Mar 2004 03:05:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 10 Mar 2004 03:05:31 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B0u2D-0004Fl-0t; Tue, 09 Mar 2004 22:05:29 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com, vinschen@redhat.com Subject: Re: [RFC/RFA] gdb.cp/classes.exp: Don't try to print local variable out of scope Message-ID: <20040310030528.GB16230@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michael Elizabeth Chastain , gdb-patches@sources.redhat.com, vinschen@redhat.com References: <20040309161507.9FBF54B104@berman.michael-chastain.com> <404E2B2C.8030201@gnu.org> <20040309212736.GA8404@nevyn.them.org> <404E45EC.4030205@gnu.org> <20040310005631.GA13440@nevyn.them.org> <404E7489.4010209@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404E7489.4010209@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00223.txt.bz2 Message-ID: <20040319000900.UK4ahQLN-pFQsxd0sjSPRr9Fm-UyH7I4Z3VAbDyDZPI@z> On Tue, Mar 09, 2004 at 08:51:05PM -0500, Andrew Cagney wrote: > > >BTW, I think the NORMAL_FRAME check is wrong too: > > > > { > > int i; > > stuff (i); > >-> } > > > >get signal > > Er, hold on. The intent of address-in-block is: > > /* An address (not necessarily alligned to an instruction boundary) > that falls within THIS frame's code block. > > When a function call is the last statement in a block, the return > address for the call may land at the start of the next block. > Similarly, if a no-return function call is the last statement in > the function, the return address may end up pointing beyond the > function, and possibly at the start of the next function. > The only way to get a PC pointing at the first instruction of a function > is for that function to have been interrupted just as that first > instruction was about to be executed -- thats the very case where the > existing address_in_block correctly leaves the PC as is. > > In the example in question: > > > > > { > > int i; > > stuff (i); > > -> } > > the existing code correctly puts the PC at the instruction about to > destroy the prologue. Think about this for a moment. I'm going to give addresses so that I can be more precise. 0x10 : ret stuff(int) { } 0x20
: push main() { 0x21 : push { 0x22 : move arg1, i stuff(i) 0x23 : call stuff " 0x24 : pop } 0x25 : pop } 0x26 : ret " The inner scope is probably to inclusive. Suppose PC == 0x10. We backtrace. Look at main; saved PC is 0x24. We want an address in the block. We subtract 1. OK, saved addr-in-block is 0x23. 'i' is in scope. Suppose PC == 0x24. Shouldn't this be the same? For the purposes of looking at local variables, aren't we still in the the block? Suppose PC was 0x24 and we got a signal. Ditto. Suppose PC == 0x20 and we get a signal. Obviously we don't want to change the behavior of this. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer