From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17869 invoked by alias); 29 Dec 2010 05:48:56 -0000 Received: (qmail 17856 invoked by uid 22791); 29 Dec 2010 05:48:55 -0000 X-SWARE-Spam-Status: No, hits=-2.0 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; Wed, 29 Dec 2010 05:48:50 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C29472BABFB; Wed, 29 Dec 2010 00:48:48 -0500 (EST) 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 QlIzPhsc7u1R; Wed, 29 Dec 2010 00:48:48 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 43DF32BABFA; Wed, 29 Dec 2010 00:48:48 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 8F53B145870; Wed, 29 Dec 2010 09:48:41 +0400 (RET) Date: Wed, 29 Dec 2010 06:08:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [RFA] unexpected multiple location for breakpoint Message-ID: <20101229054841.GF2396@adacore.com> References: <1290474625-1582-1-git-send-email-brobecker@adacore.com> <20101126172942.GK2634@adacore.com> <20101127183532.GA10136@caradoc.them.org> <20101210122337.GC2596@adacore.com> <20101228112546.GB2436@adacore.com> <83tyhxbthv.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83tyhxbthv.fsf@gnu.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-12/txt/msg00536.txt.bz2 > > If this is a bug, then the only solution I can think of is inserting > > a breakpoint at *every* instances of line 53, regardless of > > lexical-block relationships. > > When would that be worse than what we have now? I worry about the effect at -O0. It is common to see the same source line being split across the code. For instance, with conditional loops, the condition evaluation is often placed at the end of the loop, and its code is associated to the initial line. See Eg. gdb.base/call-ar-st.c, where we have: 1146 int main () { [bunch of declarations snipped] 1193 /* Initialize arrays 1194 */ 1195 for (index = 0; index < 120; index++) { 1196 if ((index%2) == 0) char_array[index] = 'Z'; 1197 else char_array[index] = 'a'; 1198 } If we try to insert a breakpoint on line 1195, we get: (gdb) break call-ar-st.c:1195 Breakpoint 1: file /[...]/call-ar-st.c, line 1195. (2 locations)^M Inspecting the line table, we find that it looks like this: 1195, 1196, 1197, and then back to 1195. So the double-location breakpoint is expected if we decide to break everywhere. There is a slight side-issue with my patch where breaking on "main" also causes 2 breakpoints to be inserted, but I consider that a buglet because we have special logic to avoid the expansion when breaking on a function (or so I thought!). (gdb) b main Breakpoint 1 at 0x401906: file /[...]/call-ar-st.c, line 1195. (2 locations) (gdb) info break Num Type Disp Enb Address What 1 breakpoint keep y 1.1 y 0x0000000000401906 in main at call-ar-st.c:1195 1.2 y 0x000000000040193f in main at call-ar-st.c:1195 Note that we also have the following explicit comment in the code: /* For optimized code, compiler can scatter one source line accross disjoint ranges of PC values, even when no duplicate functions or inline functions are involved. For example, 'for (;;)' inside non-template non-inline non-ctor-or-dtor function can result in two PC ranges. In this case, we don't want to set breakpoint on first PC of each range. [...] */ For the record, attached is the patch that I used. It was written on top of the initially proposed patch (in this thread), but just purely for convenience. The piece that checks the next entry is to avoid inserting a breakpoint on 2 blocks if the two blocks are consecutive. This is often the case with functions where the compiler emits a line entry with the same line number to mark the end of the function prologue... -- Joel