From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id F/S5MUCKRGfQGT8AWB0awg (envelope-from ) for ; Mon, 25 Nov 2024 09:31:28 -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=N9hRFvLe; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BAF751E092; Mon, 25 Nov 2024 09:31:28 -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 7F9E01E05C for ; Mon, 25 Nov 2024 09:31:27 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1CB683858D38 for ; Mon, 25 Nov 2024 14:31:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1CB683858D38 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=N9hRFvLe 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 8C25D3858C52 for ; Mon, 25 Nov 2024 14:30:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8C25D3858C52 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 8C25D3858C52 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=1732545050; cv=none; b=mZq1QoegN+ML8Och8DHUHPPZkXfkaXDrsxgK4f/NpbtHQsFy4Cp6sJN3Vm945wFkjpkeSbdgj6KpQy4tJvvq5xiRunDv5n3NmZgIgIIi6T0Z9lfntAWeqkAoCRvNFHHZzrPI1pfczyVH4I8ke04pqEUD9t8KDLUMFsTSY4aT0TQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1732545050; c=relaxed/simple; bh=Y5w0v35/0At/FaafI1qf/JymcyDF8L8VkKwuVR+6Www=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=uw+4mAn91XMA1pFIc3XkvyNg0WE35e0k18A+InT4tNP1vM1RVvncSMLKHq7+ji6fNnjYmpneays9hr4bzc4ypxg963Q8ULvJXZ58X9rkPmiQ78D6At9Y+s6UpZmgvgXxBFDhNeEzI/eBLgxgm4hcPkL8gTceThgK9LysS6cqNe4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8C25D3858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732545050; 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=7yD5MkqnyYGdovz/G3wr17rs+w3DWWIK+704g7ZpqAI=; b=N9hRFvLeAzyVDNIGQATrsx/7QEuzygliPFOBOFXr2cHUSN1tWi2smb9ckFViNLp3IFo/av 4fOsOJvNPnsXKStpZeftnKi1XA14wg0F+6YIsB3DbrUMN5MbxJuE2fxos3fcGYz9VpGcAT EhZloIPh9gVs3kUOgWA9ntjvsfLwLu8= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-581-n6-Jcf-oPz-lrF-5LC3S5g-1; Mon, 25 Nov 2024 09:30:48 -0500 X-MC-Unique: n6-Jcf-oPz-lrF-5LC3S5g-1 X-Mimecast-MFC-AGG-ID: n6-Jcf-oPz-lrF-5LC3S5g Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4349f32c9a6so8029965e9.3 for ; Mon, 25 Nov 2024 06:30:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732545047; x=1733149847; 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=7yD5MkqnyYGdovz/G3wr17rs+w3DWWIK+704g7ZpqAI=; b=Fm8GyhZZ9RnIdV0jk5elDqAmlA22+zAxcJiJQHUvUuFSz7+VeLdHAnbrdIGo4aia7z hsSD4TZZFxerwm39HzNc92BL4VkZDobBlGZVOU095MuAVpmCZuNJUJsO2lgoaoLOUSNl l6gJYjNo2zCtZc5WfFmn9u1228p7WoxOnbF7yjXSRWe2mx7yLOujQtJQcdrqXthNW1w/ LpFdVga7LXe/9UIs1IGk5S1qP0G/fB+tRkgYFyLdRff9IYR/yF6+ia2bs/0Nf0/coTb5 JWKG1UHbzBVDogAjQ/UmYykOsWE5axp4ZuUW+YsFuzxDEKuv4pjCY6slayKYhum5Oenf n/bQ== X-Forwarded-Encrypted: i=1; AJvYcCUKYlLqv+FnY90bGdrvl1CbYqwMtK7C8AXcokP3zMUuNHEaIyXrQ5ATXmGe8sTIV4oR+XRjdALZJ7ahig==@sourceware.org X-Gm-Message-State: AOJu0YwaXMLLN2DgpMJ/+5321a4nKtQEUKyQreULguTdnxscg9fKFLQv kG+glarJMCaoCcQ5tm1Rcyb5kR+MJAlaD05nslVvNJuB6/rtmXFaBAZc0/+uTsfUSH28/8PkPXy 8/NYQ8CMIWrID3DhuON2d3+2/AFt2vsmOT6lDMJv2WVHJNnBI69zZ5IR4ehQ79S4ow9g= X-Gm-Gg: ASbGncsCCn2UpSkjpWpWCoHDSIZRA4kObSOYXLRusmGmilaO/WG1t/s2ee3maL4b5DM OsA+W+cYMB+XhOoh12lVlkufuKUzbhgpC2tZ8Gh5FFjVA6Ri4EG5evnN6+7y23Zxe0SdagfS3oC VSQVrBcMb9Ed/IK+xeiVMm0p37bOM4s4muZJcDUwlEgZpK7fft7wRPw/u/fOeCjKLH9/MpdYIGB 4tKexo7dFBwY/KpNIhcXtZYmFRv8rcn836DZDlgVWQkfJy9KJg+5RnJOUsZ8M+u3YFFFh82NzzK /A== X-Received: by 2002:a05:600c:310b:b0:42e:93af:61c5 with SMTP id 5b1f17b1804b1-433ce41e542mr117280495e9.14.1732545047159; Mon, 25 Nov 2024 06:30:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IFsZ918tjCZFJTHveX+yLR6D2pI5lDXdv/HUdR0hHJMGxJFbGPSwxN3uzoRYKgou5yeq7O2pg== X-Received: by 2002:a05:600c:310b:b0:42e:93af:61c5 with SMTP id 5b1f17b1804b1-433ce41e542mr117279775e9.14.1732545046511; Mon, 25 Nov 2024 06:30:46 -0800 (PST) Received: from localhost (197.209.200.146.dyn.plus.net. [146.200.209.197]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-433b01e115asm200008185e9.6.2024.11.25.06.30.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Nov 2024 06:30:46 -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> Date: Mon, 25 Nov 2024 14:30:45 +0000 Message-ID: <877c8rmlm2.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Y4TDxtRfw-xDW_j18rnUbIkJmbdYI1nlIxXyeVO74kc_1732545048 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/22/24 17:53, Andrew Burgess wrote: >> Bernd Edlinger writes: >> >>> Hmm, sorry, but I think this goes in the wrong direction. >>> >>> On 11/20/24 16:01, Andrew Burgess wrote: >>>> The test gdb.cp/step-and-next-inline.exp creates a test binary called >>>> step-and-next-inline-no-header. This test includes a function >>>> `tree_check` which is inlined 3 times. >>>> >>>> When testing with some older versions of gcc (I've tried 8.4.0, 9.3.1) >>>> we see the following DWARF representing one of the inline instances of >>>> tree_check: >>>> >>>> <2><8d9>: Abbrev Number: 38 (DW_TAG_inlined_subroutine) >>>> <8da> DW_AT_abstract_origin: <0x9ee> >>>> <8de> DW_AT_entry_pc : 0x401165 >>>> <8e6> DW_AT_GNU_entry_view: 0 >>>> <8e7> DW_AT_ranges : 0x30 >>>> <8eb> DW_AT_call_file : 1 >>>> <8ec> DW_AT_call_line : 52 >>>> <8ed> DW_AT_call_column : 10 >>>> <8ee> DW_AT_sibling : <0x92d> >>>> >>>> ... >>>> >>>> <1><9ee>: Abbrev Number: 46 (DW_TAG_subprogram) >>>> <9ef> DW_AT_external : 1 >>>> <9ef> DW_AT_name : (indirect string, offset: 0xe8): tree_check >>>> <9f3> DW_AT_decl_file : 1 >>>> <9f4> DW_AT_decl_line : 38 >>>> <9f5> DW_AT_decl_column : 1 >>>> <9f6> DW_AT_linkage_name: (indirect string, offset: 0x2f2): _Z10tree_checkP4treei >>>> <9fa> DW_AT_type : <0x9e8> >>>> <9fe> DW_AT_inline : 3 (declared as inline and inlined) >>>> <9ff> DW_AT_sibling : <0xa22> >>>> >>>> ... >>>> >>>> Contents of the .debug_ranges section: >>>> >>>> Offset Begin End >>>> ... >>>> 00000030 0000000000401165 0000000000401165 (start == end) >>>> 00000030 0000000000401169 0000000000401173 >>>> 00000030 0000000000401040 0000000000401045 >>>> 00000030 >>>> ... >>>> >>>> Notice that one of the sub-ranges of tree-check is empty, this is the >>>> line marked 'start == end'. As the end address is the first address >>>> after the range, this range cover absolutely no code. >>>> >>>> But notice too that the DW_AT_entry_pc for the inline instance points >>>> at this empty range. >>>> >>>> Further, notice that despite the ordering of the sub-ranges, the empty >>>> range is actually in the middle of the region defined by the lowest >>>> address to the highest address. The ordering is not a problem, the >>>> DWARF spec doesn't require that ranges be in any particular order. >>>> >>>> However, this empty range is causing issues with GDB newly acquire >>>> DW_AT_entry_pc support. >>>> >>>> GDB already rejects, and has done for a long time, empty sub-ranges, >>>> after all, the DWARF spec is clear that such a range covers no code. >>>> >>>> The recent DW_AT_entry_pc patch also had GDB reject an entry-pc which >>>> was outside of the low/high bounds of a block. >>>> >>>> But in this case, the entry-pc value is within the bounds of a block, >>>> it's just not within any useful sub-range. As a consequence, GDB is >>>> storing the entry-pc value, and making use of it, but when GDB stops, >>>> and tries to work out which block the inferior is in, it fails to spot >>>> that the inferior is within tree_check, and instead reports the >>>> function into which tree_check was inlined. >>>> >>>> I've tested with newer versions of gcc (12.2.0 and 14.2.0) and with >>>> these versions gcc is still generating the empty sub-range, but now >>>> this empty sub-range is no longer the entry point. Here's the >>>> corresponding ranges table from gcc 14.2.0: >>>> >>> >>> Yeah, maybe not in this test case, but that is not true in general, >>> a quick check with gcc-15 shows that there still a number of such >>> empty range table entries in the gdb executable itself. >>> >>> Note that ignoring these entry_pc values is completely wrong, >>> and my patch series handles exactly these empty subranges, by not >>> ignoring them in the dwarf reader, and the debug experience is >>> completely normal when this happens. >>> >>> Furthermore, I think that having a break point at these PC values has >>> some benefit, because it is the earliest point in time, when all >>> the input parameter values of the inline function are available, >>> and can be inspected by gdb. >> >> I hear and understand your frustration. I'm absolutely not ignoring the >> work you've done. But I see this as a journey of small steps to get >> where you want to be. >> >> I agree with you 100% that dealing better with the empty sub-ranges is >> the right way to go, and indeed, I have just finished pulling the empty >> sub-range work from your series, and I plan to post those patches >> hopefully over the weekend, I'm just running final tests now. >> >> But, this patch does more than just deal with the case of entry-pc >> pointing at the empty sub-range. I believe that having a sanity check >> that the entry-pc is within any sub-range is the right thing for GDB to >> do, regardless of what we ultimately end up doing with empty ranges. >> >> I'm hoping I can convince you that fixing this first is not going to >> prevent us merging your empty sub-range handling code next. >> >>> I think now it is time to consider merging the rest of my >>> patch. >> >> My top priority between now and year end is to merge either your >> patches, or equivalent functionality, into GDB. But, as you can tell >> from what I've posted, I think your series covers a lot of fixes which >> should be broken into separate commits. >> >> I think the work you have done is absolutely amazing, and makes huge >> improvements to GDB's handling of optimised code, I just don't want to >> rush things, but I'm certain we will get there. >> >> Thanks, >> Andrew >> > > 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. 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. Thanks, Andrew