From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by sourceware.org (Postfix) with ESMTPS id 36F24394741E for ; Fri, 28 Aug 2020 15:24:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 36F24394741E 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-f68.google.com with SMTP id i7so724480wre.13 for ; Fri, 28 Aug 2020 08:24:05 -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=HdttVKjQdcPuLdrk1vg0Cys79jaAodZuF+DEA7+V0Ug=; b=h+C7edJ+VkTXv/G91gkzZsUQvpVUin0C8TxvHjSlcC0nnCgpXRO3hy1uthFNODLiFU AGx7THrgKH/M8veFp34waRAFPcFVbVUbVGlPoxkVpzWUsmtYzWX9seTJj7FYjbdhqPgx iNOPLCUU5KiQZWXa9ctgAlNDXcekRs6w1fub4FrwZLYScfRES9DCjZjDaUoRvEUFTUXc D8zWXU2kJCRosIZ07CawjLZUy1w/tjndH279WiYkGX1WBoTREXdONZmcA1IrkWqygjb3 Z0IjLZazmjd20X6vPQUjzBGmWyQy+ZNNcRFtBz4luU6dYLAgMWa6cRAjgCOy4yrxg5m6 zeGg== X-Gm-Message-State: AOAM533slyft/2dvFI5n+afzm3ihVwZuIASagdMHIPxmStvFEXsocYKq +o10JxN6n5hQVpzIz+Lu1FwquEpNWzD9nw== X-Google-Smtp-Source: ABdhPJxa6YEAtXxgpn1sKpfepwAp6Q8Tpa6N/sMzRApOYHGzwx6F+E91Hr8Vnp/pqfSas1/X39OO+Q== X-Received: by 2002:adf:9ed1:: with SMTP id b17mr1982883wrf.227.1598628243018; Fri, 28 Aug 2020 08:24:03 -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 f6sm3483392wme.32.2020.08.28.08.24.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Aug 2020 08:24:02 -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: <40176a97-5b2c-b430-c9f7-483b88bda81c@palves.net> Date: Fri, 28 Aug 2020 16:23:59 +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:24:06 -0000 On 8/28/20 3:30 PM, Tom de Vries wrote: > On 8/28/20 3:53 PM, Tom de Vries wrote: >> On 8/28/20 3:32 PM, Pedro Alves wrote: >>> On 8/27/20 2:49 PM, Tom de Vries wrote: >>>> On 8/27/20 2:41 PM, Pedro Alves wrote: >>>>> On 8/27/20 12:52 PM, Tom de Vries wrote: >>>>>> Hi, >>>>>> >>>>>> Consider test-case test.c: >>>>>> ... >>>>>> $ cat test.c >>>>>> int main (void) { >>>>>> return 0; >>>>>> L1: >>>>>> (void)0; >>>>>> } >>>>>> ... >>>>>> >>>>>> Compiled with debug info: >>>>>> ... >>>>>> $ gcc test.c -g >>>>>> ... >>>>>> >>>>>> When attempting to set a breakpoint at L1, which is a label without address: >>>>>> ... >>>>>> <1>: Abbrev Number: 2 (DW_TAG_subprogram) >>>>>> DW_AT_name : main >>>>>> <2><115>: Abbrev Number: 3 (DW_TAG_label) >>>>>> <116> DW_AT_name : L1 >>>>>> <119> DW_AT_decl_file : 1 >>>>>> <11a> DW_AT_decl_line : 5 >>>>>> <2><11b>: Abbrev Number: 0 >>>>> >>>>> Is this a debug info bug, >>>> >>>> Strictly speaking, this is a debug info bug. The standard says that: >>>> ... >>>> The label entry has a DW_AT_low_pc attribute whose value is the address >>>> of the first executable instruction for the location identified by the >>>> label in the source program. >>>> ... >>>> >>>> But I interpret the missing DW_AT_low_pc attribute as: there is a label >>>> in the source, but the corresponding code has been optimized out. >>>> >>>>> or is the debug info telling us that the >>>>> address of the label is the same as the line number's address? >>>>> >>>>> How about looking up the line number address instead of throwing >>>>> an error? >>>>> >>>> >>>> Well, in this particular case, that wouldn't help. >>>> >>>> With L1 at line 3: >>>> ... >>>> $ cat -n test.c >>>> 1 int main (void) { >>>> 2 return 0; >>>> 3 L1: >>>> 4 (void)0; >>>> 5 } >>>> 6 >>>> ... >>>> there's no corresponding address: >>>> ... >>>> $ readelf -wL a.out >>>> CU: test.c: >>>> File name Line number Starting address >>>> View Stmt >>>> test.c 1 0x400497 >>>> x >>>> test.c 2 0x40049b >>>> x >>>> test.c 5 0x4004a0 >>>> x >>>> test.c - 0x4004a2 >>>> ... >>>> >>>> My suspicion is that this won't be useful in general. >>> >>> I don't understand the "not useful" remark. If a user does gets >>> the error, they'll probably do: >>> >>> "b 3", >>> >>> and they'll get a breakpoint at line 5, no? >>> >>> That's very likely what a user would do after the error. >>> >>> IMO GDB should do that for the user. >>> >>> So far I don't agree with your patch. >>> >> >> 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. >> > > FWIW, lldb does the same: > ... > $ lldb a.out > (lldb) target create "a.out" > Current executable set to 'a.out' (x86_64). > (lldb) b main:L1 > Breakpoint 1: no locations (pending). > WARNING: Unable to resolve breakpoint to any actual locations. > (lldb) b 9 > Breakpoint 2: where = a.out`main + 5 at test.c:14, address = > 0x000000000040049c > (lldb) > ... Well, I don't think you can claim that because it doesn't look like lldb understands labels at all. Tweak the testcase to: 18 int 19 main (void) 20 { 21 L1: 22 return 0; 23 } And then: (lldb) b main:L1 Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. And you get the same message with any random nonexistent label name: (lldb) b main:FOOBAR Breakpoint 2: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. (lldb)