From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 10DF13858C5F for ; Tue, 18 Apr 2023 02:26:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 10DF13858C5F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hev.cc Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hev.cc Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-2f9b9aa9d75so926858f8f.0 for ; Mon, 17 Apr 2023 19:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hev-cc.20221208.gappssmtp.com; s=20221208; t=1681784778; x=1684376778; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EOPr3Tv4oP0wUwvg8Gmqqfh7pENdIIRj3PUKXEm8diQ=; b=bMx/wonm1WOSUFjToetPtJrEFFFBlZszJqMRcIMDZylRVvaKWl+1383gYXJWCK4Nak 6L3bsVdsMWiacGPhOzl21UjIoP4kfJskVFtz6totujRBDlJ+f+ZtrwNDyAicuXMhdHcj gSrQ1nE15oHd56t7G2eP8i3vs1itKmQ9MRe+zRt3cgsi4bGPcQ8B0AWSYtCgJ+pyyBO2 i6csMeEIw6Q6XW7OlehcdvxO0bip0h4FJkw6lR6y00rsJYDRtJNlgT/fVd/DM6cZpqpf TfB2qICL7BG12Btm8P1qBpGXMBWFymCckm4+QhcI0kTJC4ENCTtMu/lQY+MjvN9n1ca1 eJ+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681784778; x=1684376778; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EOPr3Tv4oP0wUwvg8Gmqqfh7pENdIIRj3PUKXEm8diQ=; b=QmU3gUXVlNSc8mIkvFZ47aX283D+7f6d5SKI2b7QmedcnDjZ7KGSVIwT973pUjqCqd tm4IGhs61TLEJvd1E13j/QP2atreyPzN6PyiThrN9lN2mZZpmoDIR8+n4nmeH0RtBdvR D4/uHh4wd6Jd9FN/4SXgA6EaZrUpGuzuX90PlC6sb31F1y7YdQAsY/dk4AkcpS7eEhLO tz3OevcmOV6jzsseVmIGcfxeTa1VWt0JIuL9AFfG/ktgvwEgA1jm4XFahKLhfsxJ2gip cxFNiPocUYH3bDTo435JMxKS6dSxfvPdxDiYjAFKbcOWepkpFUiKGhC8ORJBOAUJ6vEJ mRVw== X-Gm-Message-State: AAQBX9cMnK68b1ONS6YysYk5Dxg6mmlIStCur2d6OyJ/x/EJ1mEOyaIO T9qECe7tVhHlSDoNIM0vdTFAHtFd8Z45X5W58eTDKFaaE3BOoohQ0c/gufmpszU= X-Google-Smtp-Source: AKy350YGBkiljTx9VvvU+qGZLqWgPA2DCRR47+EsEsQ1A07Nfl/TJ0npx66ao4P4zUVRPAvZSbfcRGfFy1FfAkzG3uA= X-Received: by 2002:adf:e3d0:0:b0:2f8:5767:2d0d with SMTP id k16-20020adfe3d0000000b002f857672d0dmr568237wrm.68.1681784778383; Mon, 17 Apr 2023 19:26:18 -0700 (PDT) MIME-Version: 1.0 References: <20230417162428.48426-1-r@hev.cc> <901e6d84-2476-9108-b79c-0a3747d02b2f@redhat.com> In-Reply-To: <901e6d84-2476-9108-b79c-0a3747d02b2f@redhat.com> From: hev Date: Tue, 18 Apr 2023 10:26:07 +0800 Message-ID: Subject: Re: [PATCH] gdb: Fix false match issue in skip_prologue_using_linetable To: Keith Seitz Cc: gdb-patches@sourceware.org Content-Type: multipart/alternative; boundary="0000000000004df3e105f99308c9" X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000004df3e105f99308c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Keith, Thanks for your comments. On Tue, Apr 18, 2023 at 1:38=E2=80=AFAM Keith Seitz wro= te: > > On 4/17/23 09:24, WANG Rui wrote: > > We should exclude matches to the ending PC to prevent false matches with the > > next function, as prologue_end is located at the end PC. > > > > : > > 0x00: ... <-- start_pc > > 0x04: ... > > 0x08: ... <-- breakpoint > > 0x0c: ret > > : > > 0x10: ret <-- end_pc | prologue_end of fun2 > > Thank you for the patch. Indeed, my recollection is that we always > record/search for pc's in [start, end). find_pc_partial_function seems to > concur. > > > --- > > gdb/symtab.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/gdb/symtab.c b/gdb/symtab.c > > index f2b1a14e006..a662d7d1869 100644 > > --- a/gdb/symtab.c > > +++ b/gdb/symtab.c > > @@ -3735,7 +3735,7 @@ skip_prologue_using_linetable (CORE_ADDR func_addr) > > }); > > > > for (; > > - it < linetable->item + linetable->nitems && it->pc <=3D end_pc; > > + it < linetable->item + linetable->nitems && it->pc < end_pc; > > it++) > > if (it->prologue_end) > > return {it->pc}; > > This appears to be against gdb 13 and will need to be rebased. > > I have regression tested this on x86_64 and found nothing of concern. > [The patch which introduced this function contained a test case, > gdb.dwarf2/dw2-prologue-end.exp, and that test also shows no regressions.] > > I have to ask, though, is there a way to write a test case for this? Maybe > by using dw2-prologue-end.exp as an example? I attempted to write a test case, but it did not work. I discovered this issue while running the Rust debuginfo test[1] on LoongArch. As the function entry alignment is 4-byte, which is the size of an instruction, there is no padding between the two functions. This creates a possibility of matching the start address of the next function. This is unlike x86, which is why this problem does not occur on x86. I sincerely hope that this information proves to be beneficial to you. [1] https://github.com/rust-lang/rust/blob/7908a1d65496b88626e4b7c193c81d777005= d6f3/tests/debuginfo/box.rs -- Rui --0000000000004df3e105f99308c9--