From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17380 invoked by alias); 11 May 2009 12:56:53 -0000 Received: (qmail 17370 invoked by uid 22791); 11 May 2009 12:56:52 -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; Mon, 11 May 2009 12:56:48 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B60E32BAC34; Mon, 11 May 2009 08:56:46 -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 fhkxLIyHRIhk; Mon, 11 May 2009 08:56:46 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 809AD2BAC33; Mon, 11 May 2009 08:56:46 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 58CA0F5901; Mon, 11 May 2009 05:56:44 -0700 (PDT) Date: Mon, 11 May 2009 12:56:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [RFA] Fix "break foo" when `foo's prologue ends before line table Message-ID: <20090511125644.GD14773@adacore.com> References: <83skjebbef.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83skjebbef.fsf@gnu.org> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00212.txt.bz2 > Line table: > > line 6 at 0x1748 > line 8 at 0x1750 > line 9 at 0x1756 > line 11 at 0x176b > line 13 at 0x177b > line 14 at 0x1780 [...] > Here's the disassembly of `main', in case someone thinks that > skip_prologue function didn't do a good job (I think it did a > reasonable job, but I'm far from being an expert on prologue > analysis): Here is what the prologue looks like: > Dump of assembler code for function main: > 0x0000172c : push %ebp > 0x0000172d : mov %esp,%ebp > 0x0000172f : sub $0x8,%esp > 0x00001732 : and $0xfffffff0,%esp [this is where GDB thinks the prologue stops] > 0x00001735 : mov $0x0,%eax > 0x0000173a : add $0xf,%eax > 0x0000173d : add $0xf,%eax > 0x00001740 : shr $0x4,%eax > 0x00001743 : shl $0x4,%eax > 0x00001746 : sub %eax,%esp [this is the last instruction before the first line of code according to the line table] Regarding your question above, it really depends on whether you consider the second part of the code above as prologue or not. What the code above does is making sure that the stack is properly aligned. I am sure that some people would want to consider this as part of the prologue, and I wouldn't disagree, but others could argue the opposite, and I wouldn't disagree either. Regardless of that, however, we should really look at what "break FUNCTION" is supposed to be doing. And looking at the doc, it says: ``Specifies the line that begins the body of the function'' (this matches what I thought it should be doing intuitively). So, regardless of what GDB should be doing in terms of prologue analysis, I think we should still try to find the first line as you're doing in your patch. > + ALL_PSYMTABS (objfile, p) > + { > + if (FILENAME_CMP (symtab->filename, p->filename) != 0) > + continue; > + PSYMTAB_TO_SYMTAB (p); > + } > + > + /* Loop over all symtabs for the function's file, looking for an > + entry in a lineinfo table whose PC is in the range > + [FUNC_START..FUNC_END] and whose line number is the smallest. */ > + ALL_SYMTABS (objfile, s) I am wondering if this looping over all PSYMTAB and SYMTABs is really necessary. Is the symtab associated to your symbol not sufficient? Also, instead of returning the line whose number is the smallest, I would return the smallest PC, as we're trying to skip the minimum before inserting the breakpoint. This means that your iteration on the line table can stop as soon as you've found a non-zero line that's inside your function address range. -- Joel