From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25492 invoked by alias); 29 Dec 2010 17:57:24 -0000 Received: (qmail 25481 invoked by uid 22791); 29 Dec 2010 17:57:23 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Dec 2010 17:57:15 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LE700200B4WHB00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Wed, 29 Dec 2010 19:56:52 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.124.219.104]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LE700N2NB6P1WQ0@a-mtaout22.012.net.il>; Wed, 29 Dec 2010 19:56:52 +0200 (IST) Date: Wed, 29 Dec 2010 19:30:00 -0000 From: Eli Zaretskii Subject: Re: [RFA] unexpected multiple location for breakpoint In-reply-to: <20101229054841.GF2396@adacore.com> To: Joel Brobecker Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83oc84bgv3.fsf@gnu.org> 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> <20101229054841.GF2396@adacore.com> X-IsSubscribed: yes 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/msg00549.txt.bz2 > Date: Wed, 29 Dec 2010 09:48:41 +0400 > From: Joel Brobecker > Cc: gdb-patches@sourceware.org > > > > 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. Are you saying that GCC does that under -O0? I'd be surprised. But I realize that it does that for higher optimization levels. Still, my question is how would it be worse to have the inferior stop several times through the loop than not stop at all? > 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. That's fine, and I think it will take care of the most blatant offenders.