From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28607 invoked by alias); 20 Jun 2002 20:14:43 -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 28576 invoked from network); 20 Jun 2002 20:14:41 -0000 Received: from unknown (HELO takamaka.int.act-europe.fr) (142.179.108.207) by sources.redhat.com with SMTP; 20 Jun 2002 20:14:41 -0000 Received: by takamaka.int.act-europe.fr (Postfix, from userid 507) id B558189FBA; Thu, 20 Jun 2002 13:14:40 -0700 (PDT) Date: Thu, 20 Jun 2002 13:14:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFA] block_innermost_frame tweak Message-ID: <20020620131440.M397@gnat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-SW-Source: 2002-06/txt/msg00404.txt.bz2 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1770 I would like to make the following change: 2002-06-20 Joel Brobecker * blockframe.c (block_innermost_frame): Fix a boundary condition bug that was causing GDB to sometimes fail to find the frame executing inside the given block. I verified this change on Linux, and this introduced no regression. We found out about this problem when we tried in a very particular Ada program to print the value of a variable. Here are the details: The Ada program (sorry, I tried the equivalent C program, but the problem did not reproduce there): << procedure Try is procedure Inside is begin null; end Inside; begin declare Local : Integer := 18; begin Inside; end; end Try; >> After hitting a breakpoint inside procedure "Inside", then going one frame up, GDB should be able to print the value of "Local", but instead says: No frame is currently executing in specified block This is because selected_frame->pc points to the instruction following the call to inside (ie this is more a return address than the pc), which is right at the boundary of the block for which we are trying to find the innermost frame... Hence the change I am suggesting. OK to commit? By the way, I think we have several places where we check whether a frame is an innermost frame or not, so I think it would be useful to create a public function in frame.h that would look like this: extern int frame_innermost_p (struct frame_info *); (implemented in blockframe.c). I can submit this addition as a followup patch if you think this is a good idea. Thanks, -- Joel --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="blockframe.c.diff" Content-length: 1469 Index: blockframe.c =================================================================== RCS file: /cvs/src/src/gdb/blockframe.c,v retrieving revision 1.29 diff -u -3 -p -r1.29 blockframe.c --- blockframe.c 8 Jun 2002 18:30:14 -0000 1.29 +++ blockframe.c 20 Jun 2002 19:54:13 -0000 @@ -970,6 +970,7 @@ block_innermost_frame (struct block *blo struct frame_info *frame; register CORE_ADDR start; register CORE_ADDR end; + int innermost; if (block == NULL) return NULL; @@ -983,7 +984,18 @@ block_innermost_frame (struct block *blo frame = get_prev_frame (frame); if (frame == NULL) return NULL; - if (frame->pc >= start && frame->pc < end) + /* To evaluate if a given PC address is within a block range, + we normally check if PC is inside [block start .. block end[. + However, If FRAME is not the innermost frame, then frame->pc + normally points to the instruction *following* the call, which + means that the comparison with the block boundaries need to be + offset by one instruction. This is done by checking if PC is + inside ]block start .. block end] instead. */ + innermost = !frame->next + || frame->next->signal_handler_caller + || frame_in_dummy (frame->next); + if ((innermost && frame->pc >= start && frame->pc < end) + || (!innermost && frame->pc > start && frame->pc <= end)) return frame; } } --HlL+5n6rz5pIUxbD--