From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id O3C0FURCSGdA9gIAWB0awg (envelope-from ) for ; Thu, 28 Nov 2024 05:13:24 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=VZDlvp6F; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 428911E097; Thu, 28 Nov 2024 05:13:24 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 116971E08F for ; Thu, 28 Nov 2024 05:13:23 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 837FC3858D37 for ; Thu, 28 Nov 2024 10:13:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 837FC3858D37 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=VZDlvp6F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 807443858C66 for ; Thu, 28 Nov 2024 10:10:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 807443858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 807443858C66 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1732788618; cv=none; b=UH7kK9Xx9XoAqi3oehKs8l+AClrG38RGYwnvZhfL0Nn1y9uqC4XQ1AclN8PtrT4I5nEw6tNvutHJqKI1EKq7TG8MHx24sX516tYy4GFCWSNozFgtv3o+KM3H0rj5bjWaDOgq7nyquMhK1gYmwcmgvbFTUh1S7yUIfZW6Mbppnd4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1732788618; c=relaxed/simple; bh=d5S52A1H4sV7R1Wf+Mqzj6HTBDaSpbnLqW85VFRUi6k=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=MjSu1lWIEHznlhrLiy1gOmFeaBo+1GFOWogM5kY6znYRPaN9u/6ai8E/I788LQglBF/2hlZ2JGsxSTn5ehAntHKfHKWTfVqAMyc+UIrLO/YJX3wq5LKjHVGFM/GWMhxNegkKw/I7vZzTgh/E56VGxSfSymg/3vc4Gx3sIIIuEDI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 807443858C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732788618; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uP3VFQzHURsSAHubt1KsgSiuom20F3MxdmBQrZg6US0=; b=VZDlvp6FdirfOSXRJGQquAyLoEmtBvBTouupmi4+D9YL6feKirHatO0fOznTNXOzg3u/ug /9ResdtgcD50et8DN5IcO3KLOzBHZeNWp1/l9iptoyiKghfKrBehcPjER1krXhhuwckOns PBmj2BYPFN7ELW/d/XrAwD/ARMeZ+xs= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-255-wQwpuTECPAi0p_Y-JucWdA-1; Thu, 28 Nov 2024 05:10:16 -0500 X-MC-Unique: wQwpuTECPAi0p_Y-JucWdA-1 X-Mimecast-MFC-AGG-ID: wQwpuTECPAi0p_Y-JucWdA Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-53dd08f5299so407027e87.0 for ; Thu, 28 Nov 2024 02:10:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732788615; x=1733393415; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uP3VFQzHURsSAHubt1KsgSiuom20F3MxdmBQrZg6US0=; b=WAmO2gR3T89VscYv4mj3pcgiu5kxeFJ778whQhpn0Q5T2lpSZUDkySPzwF0zRx/XRK W01Ph64DgXE2wwJMYXJbgmAmGDukfm2pGrLOkLtRHya0VgnGMPWjYp+VlWM9zEMZ+gnG rIPe34TYAkeEdNDbRVFxvPjpgdoSJm5I+oBWSySq41zK26x8J+CbvxMIyKeE6odDmHkx k4YtFbkiypOHu8suxZjKBWQzZ/BpX6ZdF4pgYT7p2MQ446zt5YnTgvwb33izILWR806m aH/ju4HNU45hxP3oIHrHoaBFkDMguILjRsWk9R79UYJ2HPYlgtprtZ1x+OUuk6mGo4iL 0hKA== X-Forwarded-Encrypted: i=1; AJvYcCVwxTew24N36tmCq6u5zIe4U1jhOJC8/TgjX+Q+wM8Hdov8S2mhbwcaF2bQ83cIosO0PNmca2ExOyNjgQ==@sourceware.org X-Gm-Message-State: AOJu0Yy3bP8Sk9zVRU7a07zel6CMk2WpaDpFQ0NEPKXf6xhU/k6U+PCv R85yCWMoLndZGIDCLyZGd5lNcCNJCbedPaTJu8Tui/bMhfzqijswI3zXJWr1mmTjjLiBN/tIr0o 0ARnOlonakd/uSGzD24rRAmlGoY9WCRLM7+CqpZjI5JzJayVoQAklbvsFHoNBUTb9qX8= X-Gm-Gg: ASbGnct5bcCFNeUTPiOecqFhT/ykdMnwtCBdHs2WtXj33dYp9t6EankSfBQbZ5XyJWG RJ1TzKZu7LgltcHyzVHulZ6d5JOfb5PEUMqI3TKO2kwyjzByP1n3irMOdDBSYRsB+5AIe+ryhOL UZ96+JcKOpNOhln3ZdZmaXXgeIMMyFIOCK/VF5ZocPbXvKNqJj7y8Z4LgfkWdD1ULk4nGtAdFfm jvNY6AC/VZiRL7ZCyGEv0wH5r+RIcVsz2kADhPNsKRLGpEGgMWZ0+XLbt0axT+Mua3JV9nq43oD 5Q== X-Received: by 2002:a05:6512:280e:b0:53d:a012:efe3 with SMTP id 2adb3069b0e04-53df00aa1a8mr3185857e87.11.1732788614926; Thu, 28 Nov 2024 02:10:14 -0800 (PST) X-Google-Smtp-Source: AGHT+IGnD9frZG1ZMFM34IE58Pst2hk8AilXGwaiwu/5tgriMEZ/dGTZJlJKXyXjutcOkj15kZL+lw== X-Received: by 2002:a05:6512:280e:b0:53d:a012:efe3 with SMTP id 2adb3069b0e04-53df00aa1a8mr3185834e87.11.1732788614492; Thu, 28 Nov 2024 02:10:14 -0800 (PST) Received: from localhost (197.209.200.146.dyn.plus.net. [146.200.209.197]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-434aa74fec9sm48220965e9.6.2024.11.28.02.10.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Nov 2024 02:10:14 -0800 (PST) From: Andrew Burgess To: Bernd Edlinger , gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: handle DW_AT_entry_pc pointing at an empty sub-range In-Reply-To: References: <34cfe440ffd0e53843bfaf92494d29a6951fa9fd.1732114887.git.aburgess@redhat.com> <87y11bw6p3.fsf@redhat.com> <877c8rmlm2.fsf@redhat.com> <87bjy1lwcn.fsf@redhat.com> Date: Thu, 28 Nov 2024 10:10:13 +0000 Message-ID: <875xo7lldm.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: gZT-3iuudDpIMUXjwXamWVvFV0608kPGl0TFI5B8kcg_1732788615 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Bernd Edlinger writes: > On 11/26/24 18:48, Andrew Burgess wrote: >> Bernd Edlinger writes: >> >>> On 11/25/24 15:30, Andrew Burgess wrote: >>>> Bernd Edlinger writes: >>>> >>>>> Okay, I just wanted to point out that in my opinion the debug info which >>>>> points at the end of a sub-range is not incorrect, just maybe on a border >>>>> line, where the dwarf spec is unclear. So you should not say: >>>>> "after all, the DWARF spec is clear that such a range covers no code." >>>>> >>>>> But there are obviously not only cases where the entry_pc points at >>>>> an empty sub-range, but also in very rare cases the entry_pc points at >>>>> the end of a non-empty sub-range. >>>>> So could you please change the check in dwarf2_addr_in_block_ranges >>>>> from addr >= start && addr < end to addr >= start && addr <= end. >>>> >>>> Could you expand on why you believe that the DWARF spec is unclear in >>>> this regard. I came to my conclusion based on this text within the >>>> DWARF-5 specification, section 2.17.3 Non-Contiguous Address Ranges: >>>> >>>> Bounded range. This kind of entry defines an address range that is >>>> included in the range list. The starting address is the lowest address >>>> of the address range. The ending address is the address of the first >>>> location past the highest address of the address range >>>> >>>> This seems pretty clear (to me) that the end address is not part of the >>>> region covered by a range. >>>> >>> >>> Yes, but on the other hand, when we look at line table entries, each has a >>> PC and a VIEW number, and even the DW_AT_entry_pc has a DW_AT_GNU_entry_view, >>> just the range list does not have a view number, and that is inconsistent >>> with the concept of location views. >>> >>> Consider as a simple example an inline function: >>> >>> int f(int x) >>> { >>> x++; >>> return x; >>> } >>> >>> it will most likely just be compiled into one "inc eax" or similar, >>> and of course you may want to set a break point on the return statement, >>> to inspect 'x' after the increment, but that will be on 'pc == end' ! >>> >>> But if the location view number would not be missing from the rnglist >>> it would be obvious whether the corresponding view number is still within >>> subroutine and not outside. So in my opinion it is a defect in the >>> specification that it does not reflect this use case. >> >> You make an interesting argument that the specification is deficient. >> But I'm not sure how this helps with this discussion. I would like to >> avoid derailing this conversation with discussion of missing DWARF >> features. >> >>> >>>> Additionally, if we start to accept 'addr == end' then this is going to >>>> cause problems elsewhere. GDB will place a b/p at the 'end' address, >>>> but when GDB then performs block lookup, GDB will not return the block >>>> we expect, and so GDB will not report the inferior as having stopped in >>>> the scope that the user expects. >>>> >>> >>> No, because this is exactly what the core of my patch does, admittedly >>> I also modified the block lookup code a bit, to handle that case. >>> So I strongly disagree here: we have to accept 'addr == end' and other >>> corner cases, otherwise my patch won't work in the end, regardless of in >>> how many small bug-fixes it can be split up, because it depends exactly >>> on not ignoring any information while parsing the debug info. >> >> But accepting 'addr == end' only works if you also change the block >> lookup mechanism, which isn't part of this patch. This patch is based >> on the state of block lookup as it exists today. >> >> I've included a patch below which applies on top of this patch (i.e. the >> one this thread is about), it changes the check to accept 'addr == end' >> as you suggest. It also updates the test so that an inline function >> (bar) has DW_AT_entry_pc point at the 'end' address of a non-empty >> sub-range. >> >> Here's a GDB session with that patch applied: >> >> (gdb) b bar >> Breakpoint 1 at 0x401137 >> (gdb) r >> Starting program: /tmp/gdb/testsuite/outputs/gdb.dwarf2/dw2-entry-pc-in-empty-range/dw2-entry-pc-in-empty-range-4 >> >> Breakpoint 1, 0x0000000000401137 in foo () >> (gdb) maintenance info blocks >> Blocks at 0x401137: >> from objfile: [(objfile *) 0x3b11720] /tmp/gdb/testsuite/outputs/gdb.dwarf2/dw2-entry-pc-in-empty-range/dw2-entry-pc-in-empty-range-4 >> >> [(block *) 0x357e680] 0x401106..0x401185 >> entry pc: 0x401106 >> is global block >> symbol count: 1 >> is contiguous >> [(block *) 0x357e630] 0x401106..0x401185 >> entry pc: 0x401106 >> is static block >> is contiguous >> [(block *) 0x357e5e0] 0x401106..0x401185 >> entry pc: 0x401106 >> function: foo >> is contiguous >> (gdb) >> >> As you can see, GDB stops at an address which doesn't then resolve to >> the bar block. >> > > Ah, okay, thanks for the test case I looked into it and tried it out with > a gdb built with my patch. > > A breakpoint an an empty subrange works as expected, but indeed a breakpoint > at the end of a non-empty subrange does behave as you described. > But with real code examples a break point at the end of a non-empty subrange > does work, and that is because my "heuristic" which does the magic, uses > weak line-table entries near the end of a subrange to determine what to do > here. So because the test case does not have a line table at all, the > test case is not realistic in that aspect, and does not tell you what happens > here in a real world example. > > So a patch that allows for start <= addr && addr <= end should be applied, > probably with a line table that looks more like a real line table especially > at the end of a subrange, then the test should probably work out of the box. > But it is okay to do that after the rest of the series is applied. Could you include the details for what you'd like the line table to look like please, I guess from the test program you were trying. I'd like to try and get the updated test right first time! Ideally I guess I'd need the `maint info blocks` output showing the inline function block, and the `maint info line-table` output for the line table that covers the inline and its containing function. I'll get starting using my own demo programs, but I'd really like to meet your expectations on this. Thanks, Andrew