From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /e/7FmpW1WrrBS0AWB0awg (envelope-from ) for ; Sun, 18 Oct 2026 19:29:46 -0400 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=WQ309SC6; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 481A81E050; Sun, 18 Oct 2026 19:29:46 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_SBL_CSS autolearn=no autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (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 337111E04E for ; Sun, 18 Oct 2026 19:29:42 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9681D4BA23DA for ; Sun, 18 Oct 2026 23:29:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9681D4BA23DA Authentication-Results: sourceware.org; dkim=fail reason="signature verification failed" (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=WQ309SC6 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id C876B4BA2E27 for ; Sun, 18 Oct 2026 23:29:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C876B4BA2E27 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine 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 C876B4BA2E27 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792366154; cv=none; b=MVv8eYFsPbKBO38hBVQxN++MkXbENn7LZY8R0CYidBbI6Trqv813c/2048ckm/YtKuUqSkN2O7G0W7VkkeuEXdEAKUh1AFRLBve9OVgTUdHXsWsYbHPmMQmaNhtXKIDPgPlRSSlmZDHTxbrzrwp61V8VRnhdrVSb890Tcg5wyGI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792366154; c=relaxed/simple; bh=siFNwrXQEJfUMyNSGe/Y0LcokvVNdbtBEHLvfrCehCk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=LmmJ/OP7en9ophVV4iSgdLUsIXDNsI6GpDGKbeD4NXuCE9hLtvGHOSgmRVzwgenm0XMgHu7vhM50epJNMzgnEuVqSgzUoeArNyKaTzpx0jyBd+3z6NrkkVI79kl8OmRYQZ0ZMy0L9tLLRrb1dQnCUwCXExgdwVERa4JnVv9O/wU= ARC-Authentication-Results: i=1; sourceware.org; dkim=fail (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=WQ309SC6 reason="signature verification failed" DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C876B4BA2E27 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792366154; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mb1HfjYp4z9/mlcXyhDJmE+a6l+0tXWH4/utyUNtXAk=; b=WQ309SC6FyAR0GGDWNASbXV4cn8tbidlK8WNmiC9ONqv8bCtS6w4drEyohfP2m8RTby4LI HPE92OrWDEzwmjVlAi7LbJU0Sm85j8dV4Rci1G2RQS4NXGDGeGCSfXifOj5AlWUaKbdHV/ gFw/oGWBXxCyFSolPOzobR9+5emfQ74= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-574-CVkPkXprOp-YBMIr8bCkhg-1; Sun, 18 Oct 2026 23:29:11 +0000 X-MC-Unique: CVkPkXprOp-YBMIr8bCkhg-1 X-Mimecast-MFC-AGG-ID: CVkPkXprOp-YBMIr8bCkhg_1792366151 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 98FFF1956050; Sun, 18 Oct 2026 23:29:10 +0000 (UTC) Received: from [100.90.172.125] (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B52461803A51; Sun, 18 Oct 2026 23:29:09 +0000 (UTC) Message-ID: Date: Sun, 18 Oct 2026 16:29:07 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] gdb/dwarf: filter discarded zero-address variables after relocation To: Longjun Luo , gdb-patches@sourceware.org References: <20261009174623.2894733-1-luolongjuna@gmail.com> <20261016040017.1155012-1-luolongjuna@gmail.com> From: Kevin Buettner In-Reply-To: <20261016040017.1155012-1-luolongjuna@gmail.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 9Hj99Q49A_0yDfzzdK7WL7gPEqVPWxIX9KjjPvFateU_1792366151 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 Hi Longjun, This looks pretty good. I just have a few nits... On 10/15/26 9:00 PM, Longjun Luo wrote: > A variable discarded by section GC can retain a DIE with a zero DWARF > address. var_decode_location adds the section offset before new_symbol > checks that address. If the objfile has already been relocated, the > symbol survives the zero-address check and can read the ELF header as > data. > > This affects PIE executables when the CU is first expanded after > starting the program. It also affects normally loaded shared libraries, > including with --readnow, because their objfiles already have a load > offset. > > Have var_decode_location return the address it decoded before > relocation, and check that address in new_symbol, as the DWARF reader > already does for discarded functions and address ranges. Preserve the > existing exception for objects with allocated sections at zero. > > Extend gdb.dwarf2/dw2-var-zero-addr.exp with a PIE whose CU is first > expanded after starting the program, and with a loaded shared library, > with and without --readnow. Use a distinctive variable name to avoid > clashes with shared-library debug symbols after the program starts. > > Tested on x86_64 GNU/Linux with GCC. Without the fix, the three new > cases fail; with it, the test passes. GDB selftests pass. > > Signed-off-by: Longjun Luo > --- > v1: https://inbox.sourceware.org/gdb-patches/20261009174623.2894733-1-luolongjuna@gmail.com/ > > Changes in v2: > - Use a test-specific variable name to avoid clashes with symbols from > shared-library debug information. No reader changes. > > Linaro CI on ARM and AArch64 reported failures in the three new cases: > > (gdb) print &var > Can't take address of "var" which isn't an lvalue. > > After the discarded test variable is filtered out, the lookup can > find an unrelated symbol with the same name. I reproduced this on > x86_64 with a same-named enumerator in shared-library debug > information. The renamed test passes with and without those symbols. > > Re-tested on x86_64 GNU/Linux with GCC, Clang and cc-with-gdb-index > (7 PASS each). The three added cases still fail without the fix. > All 195 selftests pass. A full native testsuite comparison, with > differing cases rechecked, found no new regressions; existing failures > and test-driver errors remained in both variants. > > As in v1, I do not have an FSF copyright assignment for GDB and have > signed off this patch under the DCO. The GDB project does not yet accept contributions under the DCO. (It's something which is under discussion though; I'd very much like to see it happen.) IMO, this fix is of a size that is "legally significant". We'll need a copyright assignment, I think. > gdb/dwarf2/read.c | 27 +++++---- > gdb/testsuite/gdb.dwarf2/dw2-var-zero-addr.S | 2 +- > .../gdb.dwarf2/dw2-var-zero-addr.exp | 60 ++++++++++++++++++- > 3 files changed, 76 insertions(+), 13 deletions(-) > > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index 1fc6d7ffb4f..48c1100b645 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -514,9 +514,8 @@ show_dwarf_synchronous (struct ui_file *file, int from_tty, > > /* local function prototypes */ > > -static void var_decode_location (struct attribute *attr, > - struct symbol *sym, > - struct dwarf2_cu *cu); > +static std::optional var_decode_location > + (struct attribute *attr, struct symbol *sym, struct dwarf2_cu *cu); > > static unsigned int peek_abbrev_code (bfd *, const gdb_byte *); > > @@ -15160,7 +15159,11 @@ dwarf_decode_line_header (sect_offset sect_off, struct dwarf2_cu *cu, > &cu->header, comp_dir); > } > > -static void > +/* Decode the DW_AT_location attribute ATTR of SYM. If ATTR is a single > + DW_OP_addr, DW_OP_addrx or DW_OP_GNU_addr_index, return its address > + before relocation. */ Thanks for adding this comment. Could you also mention what the return value is when ATTR isn't one of the mentioned ATTRs? E.g., something like "Otherwise, return std::nullopt." I noticed, too, that two of the three callers discard the return value. This might be worth a one line comment at the call site, though there are plenty of cases where this is not done. I'll leave it to you to decide whether those sites deserve a comment. Kevin