From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8928 invoked by alias); 28 Aug 2009 16:03:42 -0000 Received: (qmail 8495 invoked by uid 22791); 28 Aug 2009 16:03:40 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Aug 2009 16:03:33 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id DBC7010928; Fri, 28 Aug 2009 16:03:30 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id B1F18108C6; Fri, 28 Aug 2009 16:03:30 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1Mh3vE-0008QT-Rt; Fri, 28 Aug 2009 12:03:28 -0400 Date: Sat, 29 Aug 2009 14:00:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb@sourceware.org Subject: Re: change of behavior in block_innermost_frame... ("inline" patch?) Message-ID: <20090828160328.GA30945@caradoc.them.org> Mail-Followup-To: Joel Brobecker , gdb@sourceware.org References: <20090828151710.GI6540@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090828151710.GI6540@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-08/txt/msg00268.txt.bz2 On Fri, Aug 28, 2009 at 11:17:10AM -0400, Joel Brobecker wrote: > Hi Daniel, > > I was trying to resync AdaCore's patches vs the current HEAD sources > at the FSF, and I noticed that there was a slight change in behavior > inside block_innermost_frame. I wanted to have your thoughts on this. > > The situation we have is that we have a nested procedure from which > we're trying to print the value of a variable defined in the outer > procedure. In other words: > > procedure Test_Nesting is > N: Integer; > procedure Inner1 (Y: INTEGER) is > begin > if (Y < N) then > Inner1 (Y * 2); > else > --gdb: break nesting.adb:15 > --gdb: cont > Put (Integer'Image (Y)); -- BREAK > > We stopped at the last quoted line ("BREAK"), and tried to print > the value of N. Normally, what would happen is that value_of_variable > calls block_innermost_frame to find the frame where this variable > is defined (in my case frame #6), and then pass that frame to > read_var_value for actual reading. What happens in that case is > that we changed the logic of block_innermost_frame to use the > block.c::contained_in function to match the frame to our given block, > which relies on superblock relationship. As a result, in my case > above, block_innermost_frame now returns frame 0 (which corresponds > to procedure Inner1), because the corresponding block is in fact > contained in the block I'm looking for. This is of course the wrong > frame to be using in order to print variable N :-(. > > I was wondering what was the reason for the change. I would like to fix > the issue while at the same time not causing a regression... Any additional > thoughts? The old version of block_innermost_frame did this: calling_pc = get_frame_address_in_block (frame); if (calling_pc >= start && calling_pc < end) return frame; Suppose calling_pc is at the location of an inlined function. We don't want to print variables of the caller looking at the inlined function; they're not in scope. The comment of block_innermost_frame is a bit ambiguous for your example: /* Return the innermost stack frame executing inside of BLOCK, or NULL if there is no such frame. If BLOCK is NULL, just return NULL. */ It does make sense that the nested function's frame would be executing inside of the outer function's block. It also makes sense that it wouldn't be. Anyway, you don't want it to be. I think contained_in is going to have to be where you fix this. I remember a lot of headaches about nested functions. Having the same block representation for nested functions and for inlined functions is confusing. Anyway, see block_linkage_function for an analogous check in the opposite sense. contained_in must want something like: if (BLOCK_FUNCTION (a) != NULL && !block_inlined_p (a)) return 0; Something trickier will be required if this function is ever passed a global or static block at file scope. -- Daniel Jacobowitz CodeSourcery