From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22474 invoked by alias); 28 Aug 2009 15:17:22 -0000 Received: (qmail 22466 invoked by uid 22791); 28 Aug 2009 15:17:21 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Aug 2009 15:17:14 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0DD552BAC04 for ; Fri, 28 Aug 2009 11:17:12 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IVcFS8NhbEVR for ; Fri, 28 Aug 2009 11:17:11 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E77522BAB53 for ; Fri, 28 Aug 2009 11:17:11 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id AC9BDF58DF; Fri, 28 Aug 2009 11:17:10 -0400 (EDT) Date: Fri, 28 Aug 2009 15:35:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: change of behavior in block_innermost_frame... ("inline" patch?) Message-ID: <20090828151710.GI6540@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00265.txt.bz2 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? Thanks, -- Joel