From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 65ecM8B/umoVHhIAWB0awg (envelope-from ) for ; Mon, 28 Sep 2026 10:54:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1790607296; bh=R2kKIdrPKLd2dHfIxIG3JAGOE8DcwV11gvjHZn1fR7w=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=EpoUoLkbFGv467xXsk57nMQ7sY83/hTr9OQX3qwISS2tbddnvaKcqrWXG1XAI/tPU 0QN1h/OMApJcyynmcQgEGY4836UNnHItB1jDAKi8oMaz7g8ljRSv70Zz/L98pwyUs5 3VEIx3SJuPUCXkky2+h8SuSYSDjYiC7qqgGYSCXQ= Received: by simark.ca (Postfix, from userid 112) id C17DA1E06B; Mon, 28 Sep 2026 10:54:56 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=HL58gAod; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 C4FF71E01F for ; Mon, 28 Sep 2026 10:54:55 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8CC084BAE7FE for ; Mon, 28 Sep 2026 14:54:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8CC084BAE7FE Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=HL58gAod Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 960294B9DB63 for ; Mon, 28 Sep 2026 14:54:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 960294B9DB63 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 960294B9DB63 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790607268; cv=none; b=vVs5VZPdOrEhSdm+KWC3UnorxJAdFmrpizuIqlFxEt5+GR0FUZqUT+6iHEf5x14AK8xV2UUQ5M7bAOT25iFoPMNQ2EYwYjsGEe6i8mMu6QQM+vvY0mhggwH3C6jrFdnw95dfZKGSP9Bm16fcwABNXJZB3KtENrpq0fyMDFsAOAE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790607268; c=relaxed/simple; bh=R2kKIdrPKLd2dHfIxIG3JAGOE8DcwV11gvjHZn1fR7w=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=kdaNl6LKzODvcz0w/DR75FmFRHhIKJlzRlSUsVtj3bUp1X2eCu8eh7GhHnPA+RDrB9ZOihtAb7A0XGRZl0++OsQU5ExsDoqaSZl+j/VgS7ZMkYGAONTKrC2wlDJadsrhlFBcYL+DmN9COrsgpHjoNdwBnKLCFdBVzBJ64NXe3NU= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=HL58gAod DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 960294B9DB63 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1790607262; bh=R2kKIdrPKLd2dHfIxIG3JAGOE8DcwV11gvjHZn1fR7w=; h=Date:Subject:To:References:From:In-Reply-To:From; b=HL58gAodzUocO1yoazcHdTfW4DpTDy4VEuB5wdXc76iy6nqTcy1jZLmeWbYXGGusj gBVxN0pJjJalC29SjbC5nhd/orWz75LlOuT84MSHKXMmxdosEpFX9CKMjPW5VGUOtr FaADA7iEY7aMoB/qwm86iTo8DFCcJfihu3iMb3Rs= Received: by simark.ca (Postfix) id 8C9381E01F; Mon, 28 Sep 2026 10:54:21 -0400 (EDT) Message-ID: Date: Mon, 28 Sep 2026 10:54:20 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] [gdb] Detect corrupt link map with zero l_ld and l_addr To: Tom de Vries , gdb-patches@sourceware.org References: <20260927063055.1997027-1-tdevries@suse.de> Content-Language: fr From: Simon Marchi In-Reply-To: <20260927063055.1997027-1-tdevries@suse.de> 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 On 9/27/26 2:30 AM, Tom de Vries wrote: > On ppc64le-linux (AlmaLinux 9.8), I run into: > ... > FAIL: gdb.mi/mi-dlmopen.exp: still-in-use fields were all correct > ... > > While investigating this, I stumbled on this warning emitted during the > calculation of allow_dlmopen_tests: > ... > (gdb) run ^M > Starting program: allow_dlmopen_tests.x ^M > [Thread debugging using libthread_db enabled]^M > Using host libthread_db library "/lib64/libthread_db.so.1".^M > warning: .dynamic section for "/lib64/ld64.so.2" is not at the expected \ > address (wrong library or version mismatch?)^M > dlmopen debug supported.^M > ... > > The warning is mentioned in this glibc commit 88361b408b: > ... > elf: Copy l_addr/l_ld when adding ld.so to a new namespace > > When add ld.so to a new namespace, we don't actually load ld.so. We > create a new link map and refers the real one for almost everything. > Copy l_addr and l_ld from the real ld.so link map to avoid GDB warning: > > warning: .dynamic section for ".../elf/ld-linux-x86-64.so.2" is not at \ > the expected address (wrong library or version mismatch?) > > when handling shared library loaded by dlmopen. > ... > > So, AFAICT the setup is: > - the glibc package is based on v2.34 > - it contains a backport of commit a93d9e03a3 ("Extend struct r_debug to > support multiple namespaces [BZ #15971]") > - it doesn't contain a backport of commit 88361b408b ("elf: Copy l_addr/l_ld > when adding ld.so to a new namespace") [1] > - both commits are part of v2.35 > > What happens is: > - when probing for l_addr and l_ld in svr4_solib_ops::read_lm_info, both get > the value 0 > - in svr4_solib_ops::lm_addr_check, the 0 value propagates to l_dynaddr, and > "l_addr = l_dynaddr - dynaddr" then underflows, and things go downhill from > there, resulting in the warning and eventually the FAIL. > > Fix this by detecting the situation in svr4_solib_ops::read_so_list, and > bailing out with a warning. > > Add detection of this and other "corruption" warnings in allow_dlmopen_tests > to make sure the related test-cases are skipped. > > In more detail, before this patch we have: > ... > $ gdb -q -batch outputs/gdb.base/dlmopen/dlmopen -ex start -ex next \ > -ex "pipe info shared | ld64" > ... > warning: .dynamic section for "/lib64/ld64.so.2" is not at the expected \ > address (wrong library or version mismatch?) > ... > 0x00007ffff7f80000 0x00007ffff8000000 0 Yes /lib64/ld64.so.2 > 0x0000000000000160 0xffffffffffff0000 1 Yes /lib64/ld64.so.2 > ... > and after: > ... > warning: Corrupted shared library entry: zero l_addr and l_ld > warning: Corrupted shared library entry: zero l_addr and l_ld > ... > 0x00007ffff7f80000 0x00007ffff8000000 0 Yes /lib64/ld64.so.2 > ... > > Alternatively, we could prevent the underflow in svr4_solib_ops::lm_addr_check: > ... > bool l_addr_updated = false; > if (l_dynaddr >= dynaddr) > { > l_addr = l_dynaddr - dynaddr; > l_addr_updated = true; > } > > if (l_addr_updated > && (l_addr & (minpagesize - 1)) == 0 > && (l_addr & align) == ((l_dynaddr - dynaddr) & align)) > ... > but we'd still get an incorrect range: > ... > warning: .dynamic section for "/lib64/ld64.so.2" is not at the expected \ > address (wrong library or version mismatch?) > ... > 0x00007ffff7f80000 0x00007ffff8000000 0 Yes /lib64/ld64.so.2 > 0x0000000000060000 0x0000000000080000 1 Yes /lib64/ld64.so.2 > ... > > FTR, in an earlier attempt I proposed to deal with the FAIL using an > xfail [2]. And in an another attempt I proposed to deal with it by > replicating the glibc fix in gdb [3]. > > Changed in v2: > - fixed incorrect footnote reference > - made comment more precise > - use "AlmaLinux" consistently > > Versions: > - v1 https://sourceware.org/pipermail/gdb-patches/2026-September/230275.html > > Tested on ppc64le-linux and x86_64-linux. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33662 > > [1] https://bugs.almalinux.org/view.php?id=667 > [2] https://sourceware.org/pipermail/gdb-patches/2026-July/229073.html > [3] https://sourceware.org/pipermail/gdb-patches/2026-August/229549.html > --- > gdb/solib-svr4.c | 23 +++++++++++++++++++++++ > gdb/testsuite/lib/gdb.exp | 3 +++ > 2 files changed, 26 insertions(+) > > diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c > index c4af1b11a4d..810b0fae7a3 100644 > --- a/gdb/solib-svr4.c > +++ b/gdb/solib-svr4.c > @@ -1333,6 +1333,29 @@ svr4_solib_ops::read_so_list (svr4_info *info, CORE_ADDR lm, CORE_ADDR prev_lm, > if (*name == '\0' || match_main (name.get ())) > continue; > > + gdb_byte dummy; > + if (li->l_addr_inferior == 0 && li->l_ld == 0 > + && target_read_memory (0, &dummy, 1) != 0) > + { > + /* We have l_addr_inferior == 0 and l_ld == 0 (corresponding to link > + map entries l_addr and l_ld). This can happen with a glibc that: > + - has commit a93d9e03a3 ("Extend struct r_debug to support > + multiple namespaces [BZ #15971]"), but > + - misses commit 88361b408b ("elf: Copy l_addr/l_ld when adding > + ld.so to a new namespace"). > + This seems to be the case at least for the AlmaLinux 9.8 BaseOS > + version, which uses glibc v2.34 and backports only the first > + commit ( https://bugs.almalinux.org/view.php?id=667 ). > + Detect this here and bail out. Otherwise, we'll present > + the user with incorrect info for "info shared". > + > + The target_read_memory is there to detect the improbable > + situation that address 0 is mapped, in which case it might be the > + address of the dynamic section. */ > + warning (_("Corrupted shared library entry: zero l_addr and l_ld")); > + return 0; > + } Returning 0 means we stop reading the shared library list, is that expected? The known case of this isn't really that the shared library list is corrupted, just that this entry is incomplete. We could maybe skip over this entry and keep reading the list, to be able to present all the loaded shared libraries to the user? Is the warning printed every time the library list is read (like at each stop)? Does that become annoying for the user? In the end maybe we don't care too much about these concerns, because it's for one specific version of one specific distro, and only when debugging programs that use multiple namespaces (which are quite rare I think). Simon