From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by sourceware.org (Postfix) with ESMTPS id 281E43861002 for ; Fri, 28 Aug 2020 13:32:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 281E43861002 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-wm1-f67.google.com with SMTP id b79so921337wmb.4 for ; Fri, 28 Aug 2020 06:32:53 -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=tzjUQ2Vf/KGHVcICBZAGxgpAaaUtp5IO/Ke1NW/wg+k=; b=HammBG8fQXeiu6pxls2OSOW6/zjamNQZ12qtsqQ2YcwKsiThD91+Wh5DaZlTroGHxA dpTWB8G5VmkE7tiEj46hSrTAk3FmVIl9+Yof9BeTuEoKsOxcxaZfJHAo8myfZw/2x8qU 2h6acD+y5LnZEJC3TGpSD3WMQpBRK4EOSNTkA0AvJjbdqctERuaFlvZ6hb/ifFFP0tWs QkCRCHuocjqJ/g3OJzEyQob5GxcxnnLs6gvyGwlY7wPtPMLBBGjLXTiOv3k0zKdN22i+ GFjwnJ4mXDiPrfwYmkesHbJLTLapkq1TGH20ZCHk2KBkbYy2KL5d6EFr7jWoOzXVLi0l m4Lg== X-Gm-Message-State: AOAM530iyxVXy0QEl+NIDBQudqPYP0sk7X5k73trAL2J4NbEhvU+ZeA7 k3etueLW6/hssdt7/pV13Mpur2RTh5BiyQ== X-Google-Smtp-Source: ABdhPJz5SsZ6e+GAmS37odzuwmCcYANuQLHTssATq1HzQA/g2sfoxVQi6+dj9KeW2JqVHAXAeoRSsg== X-Received: by 2002:a1c:e18a:: with SMTP id y132mr1740530wmg.185.1598621571330; Fri, 28 Aug 2020 06:32:51 -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 11sm2274462wmo.23.2020.08.28.06.32.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Aug 2020 06:32:50 -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> From: Pedro Alves Message-ID: <7efc1cdf-5e48-9d46-0182-6bc2318d914b@palves.net> Date: Fri, 28 Aug 2020 14:32:49 +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: <29930a75-5de9-43ed-6a24-2909eb70ec66@suse.de> 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 13:32:54 -0000 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.