From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26285 invoked by alias); 10 Mar 2004 01:51:11 -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 25800 invoked from network); 10 Mar 2004 01:51:06 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 10 Mar 2004 01:51:06 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 671352B92; Tue, 9 Mar 2004 20:51:05 -0500 (EST) Message-ID: <404E7489.4010209@gnu.org> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz 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 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> In-Reply-To: <20040310005631.GA13440@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00220.txt.bz2 > 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. These methods make an allowance for this. For call frames, this function returns the frame's PC-1 which "should" be an address in the frame's block. */ and: /* If THIS frame is not inner most (i.e., NEXT isn't the sentinel), and NEXT is `normal' (i.e., not a sigtramp, dummy, ....) THIS frame's PC ends up pointing at the instruction fallowing the "call". Adjust that PC value so that it falls on the call instruction (which, hopefully, falls within THIS frame's code block. So far it's proved to be a very good approximation. See get_frame_type for why ->type can't be used. */ It's not possible to construct my senario: >daniel: >> If that's right, it sounds like we should be using the address-in-block >> hack to figure out what local variables are in scope for the top >> frame. But that runs the risk of, for instance, moving us back into a >> preceeding function. > > > Er, that sounds like a theoretical address-in-block bug? The value returned should be floored by (as in can't be less than) the function start. Can you think of an edge case that makes this real? 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. > Use the sigtramp saved PC unmodified, and it leaves you in the right > function - but that doesn't mean it leaves you in the right block! > > Maybe something like (considering recent discussion about > get_frame_func): > > /* Return an address of that falls within the frame's code block. */ > > CORE_ADDR > get_frame_address_in_block (struct frame_info *this_frame) > { > /* A draft address. */ > CORE_ADDR pc = get_frame_pc (this_frame); > CORE_ADDR func = get_frame_func (this_frame); > > if (pc != func) > pc--; > > return pc; > } > > Note that this doesn't work for functions with discontiguous address > ranges, which GCC will soon be generating; but neither does anything > else in GDB, so we can tackle that with a fixme :) Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26285 invoked by alias); 10 Mar 2004 01:51:11 -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 25800 invoked from network); 10 Mar 2004 01:51:06 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 10 Mar 2004 01:51:06 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 671352B92; Tue, 9 Mar 2004 20:51:05 -0500 (EST) Message-ID: <404E7489.4010209@gnu.org> Date: Wed, 10 Mar 2004 01:51:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz 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 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> In-Reply-To: <20040310005631.GA13440@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00220.txt Message-ID: <20040310015100.mPyN0bBddW-tVlTupue3LosSrmmfiYUJeMGZzlWuO84@z> > 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. These methods make an allowance for this. For call frames, this function returns the frame's PC-1 which "should" be an address in the frame's block. */ and: /* If THIS frame is not inner most (i.e., NEXT isn't the sentinel), and NEXT is `normal' (i.e., not a sigtramp, dummy, ....) THIS frame's PC ends up pointing at the instruction fallowing the "call". Adjust that PC value so that it falls on the call instruction (which, hopefully, falls within THIS frame's code block. So far it's proved to be a very good approximation. See get_frame_type for why ->type can't be used. */ It's not possible to construct my senario: >daniel: >> If that's right, it sounds like we should be using the address-in-block >> hack to figure out what local variables are in scope for the top >> frame. But that runs the risk of, for instance, moving us back into a >> preceeding function. > > > Er, that sounds like a theoretical address-in-block bug? The value returned should be floored by (as in can't be less than) the function start. Can you think of an edge case that makes this real? 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. > Use the sigtramp saved PC unmodified, and it leaves you in the right > function - but that doesn't mean it leaves you in the right block! > > Maybe something like (considering recent discussion about > get_frame_func): > > /* Return an address of that falls within the frame's code block. */ > > CORE_ADDR > get_frame_address_in_block (struct frame_info *this_frame) > { > /* A draft address. */ > CORE_ADDR pc = get_frame_pc (this_frame); > CORE_ADDR func = get_frame_func (this_frame); > > if (pc != func) > pc--; > > return pc; > } > > Note that this doesn't work for functions with discontiguous address > ranges, which GCC will soon be generating; but neither does anything > else in GDB, so we can tackle that with a fixme :) Andrew