From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by sourceware.org (Postfix) with ESMTPS id B258939450E1 for ; Fri, 28 Aug 2020 15:14:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B258939450E1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wr1-f43.google.com with SMTP id x7so1632943wro.3 for ; Fri, 28 Aug 2020 08:14:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=E+sYmaKARGlqOobvbWftAmOH3OtTGOgbrGfenZQDGbI=; b=BAx2M1DRlKNtbdgCsDNzWi9ZscKHIwTRaJlOm4v7FBNYhWoDCyFmuCvErUHI2DkEMX Vi/YrtYZADLO3rbu8zjHGv7hYQ8z+5cPR0TDXUOa8AsPSRvdMl8IDlowvt7SZZvBUb4Z lZiTlYKCym2p3h+HbdjNWQiOU7ShjL37CALDjVsl6SWbL+LaU4kO1iC4mT53JPUWVzBo oB/kpK0655//QQror4vdaZua38FTaVTWORQp5p4JVWl/LUpuIbO/qKe7DX9hbfy9M5e0 Cj5Impj1FbUAKZ6570Nk/mG5Bju9cSPsBcIeIvvC5dC8BHO3RSjP8VzUnlbFNcZdKgWL fmzQ== X-Gm-Message-State: AOAM530oCMocMxTjkjjy0qxnKxtv6rNbgO1RfsJjZKo2lZ2cjOg/uyRU 9q5/MJ6JzFNoFa+jRj0SOUhCIunlRALr7A== X-Google-Smtp-Source: ABdhPJwRBU3izOcZVH1AmKOR9qr52Ay86i4+R4Lmyt4bPhdc6EoLTN/b2RkexoVM/lGLcsHQr7bl3g== X-Received: by 2002:adf:f10a:: with SMTP id r10mr1891426wro.86.1598627646258; Fri, 28 Aug 2020 08:14:06 -0700 (PDT) Received: from ?IPv6:2001:8a0:f905:5600:56ee:75ff:fe8d:232b? ([2001:8a0:f905:5600:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id b131sm2992901wmc.8.2020.08.28.08.14.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Aug 2020 08:14:05 -0700 (PDT) Subject: Re: [PATCH][gdb/breakpoint] Handle setting breakpoint on label without address To: Tom de Vries , gdb-patches@sourceware.org References: <20200827115217.GA17450@delia.home> <23b43acc-9846-a03c-5207-3ae80efc1d6f@palves.net> <29930a75-5de9-43ed-6a24-2909eb70ec66@suse.de> <7efc1cdf-5e48-9d46-0182-6bc2318d914b@palves.net> From: Pedro Alves Message-ID: Date: Fri, 28 Aug 2020 16:14:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 15:14:10 -0000 On 8/28/20 2:53 PM, Tom de Vries wrote: > I see what you mean, but let's try this counter-example: > ... > cat -n test.c > 1 int > 2 main (void) > 3 { > 4 goto L2; > 5 > 6 L3: > 7 return 0; > 8 > 9 L1: > 10 (void)0; > 11 return 1; > 12 > 13 L2: > 14 goto L3; > 15 } > 16 > ... > compiled like this: > ... > $ gcc test.c -g > ... > > With the patch, we're not able to set a breakpoint at L1, and setting > the breakpoint at the corresponding line, line 9: > ... > $ gdb a.out > Reading symbols from a.out... > (gdb) b main:L1 > Location main:L1 not available > (gdb) b 9 > Breakpoint 1 at 0x40049c: file test.c, line 14. > (gdb) > ... > yields a breakpoint at line 14, a piece of code that's not reachable > from L1. > > To me, label L1 and line 14 are unrelated enough to convince me to not > do this automatically. Well, OK. All the code after line 7 is unreacheable. Then using that rationale, why don't we reject a breakpoint at line 9 too? Line 14 is not reacheable from line 9 either. Can you justify the difference in a small sentence/paragraph? It would be perhaps nice if "break" accepted an option to prevent the move-to-following-insn -- for all kinds of breakpoints -- like lldb's "break set -m" option: -m ( --move-to-nearest-code ) Move breakpoints to nearest code. If not set the target.move-to-nearest-codesetting is used. BTW, I noticed that, setting the breakpoint at the label _after_ running to main "works": Reading symbols from testsuite/outputs/gdb.base/label-without-address/label-without-address... (gdb) b main:L1 Location main:L1 not available (gdb) start Temporary breakpoint 1 at 0x1131: file testsuite/gdb.base/label-without-address.c, line 21. Starting program: testsuite/outputs/gdb.base/label-without-address/label-without-address Temporary breakpoint 1, main () at testsuite/gdb.base/label-without-address.c:21 21 return 0; (gdb) b main:L1 Breakpoint 2 at 0x555555554000: file testsuite/gdb.base/label-without-address.c, line 22. (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x0000555555554000 main:L1 I see the same with your more complicated example. What's going on here?