From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id mQZ5OSXDmmqeZigAWB0awg (envelope-from ) for ; Fri, 04 Sep 2026 09:09:57 -0400 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=Y4q+Ykw7; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D452F1E166; Fri, 04 Sep 2026 09:09:57 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.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,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 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 B48E71E09B for ; Fri, 04 Sep 2026 09:09:56 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C24F74BB3BAE for ; Fri, 4 Sep 2026 13:09:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C24F74BB3BAE 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=Y4q+Ykw7 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 4FD314BA79B9 for ; Fri, 4 Sep 2026 13:09:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4FD314BA79B9 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 4FD314BA79B9 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=1788527372; cv=none; b=CgHbTWIYeH2OG3L8wIBPh6IUuW8GdWt4dF/43sgIO5gJpC7XniDfJ2xn3wmdq8yyiuqCA4tdhZIHO0nzb0nmAJYVWAJ5cOeu/xrSN4bZJNr8FtWqMpRalKwKPl5iNoRCxF7RTqdnYJxNYRRyruN0s2Bl4KgW2Kbcm40lnvpU2UA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788527372; c=relaxed/simple; bh=afbXimMlMVEvyh9jfchbsu35r6iWRAPEw6bKpGq+t7E=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=DnyLbmrM4+lGz9KeY9jMuYn/uSns7weYN3yezFOguT2QIq624y5riC/RuYaHe0mMWp2cq2brlQULeaSaCitB5uytfQBPfmGLVlRM4tMLQZ9nrSmGBi/DPp8+0kkwqSC+pfB8GKYDi6sRAWEmvQkooxrwk6E39lgDl8vKa72OW9U= ARC-Authentication-Results: i=1; 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=Y4q+Ykw7 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4FD314BA79B9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788527372; 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=hO5arfg1tCiMTbUzZjnr+LEOex05F2RQDphwalfi1Ok=; b=Y4q+Ykw7Y0VxCsg2/r/7ptOFsMYF24Q7NeAwzkXFB5/54oXhwYJim5WvVPJJv+YU8NSoMs UBgDUdONITh1ZL68mX9VbPKdB9178X9asTYLJbjZ6MF7V8uxaCDdr/MWmTc5BJ5TzRGJ2B BwpTARTzFzu4jSD1dHrh/8eW9nVuEZ8= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-158-eHLJIoqxOkmzVgEpgDmQPg-1; Fri, 04 Sep 2026 09:09:29 -0400 X-MC-Unique: eHLJIoqxOkmzVgEpgDmQPg-1 X-Mimecast-MFC-AGG-ID: eHLJIoqxOkmzVgEpgDmQPg_1788527368 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-48589603501so503697f8f.3 for ; Fri, 04 Sep 2026 06:09:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788527368; x=1789132168; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=hO5arfg1tCiMTbUzZjnr+LEOex05F2RQDphwalfi1Ok=; b=nFPaBpeOPC6O+efgbQRiDwFcS1hPoyPuksYWLSsM0J4UFwwkxPMdRNnoicXhkjyMTJ RvMpwAlgRbMRDYqhH5UTNRWSm8O10dEjrkUkfKdPd0VD9CbNessPe9Y4wiowM4on450m +pyTTVU4Iu6YFnShBIaqCEbPGRWkauAh8Z1vVjz184DPEndli7/Dx/hZZd3WskO/vXQo mPzG1ZDamVSb1TZUo12ZvuuEgbZ8Cnh9bw4Zd9ksl/JOx/UCk30xjEqyxSc4jei2okTp hqprFSLfSUZKDy2/lboNwGqvuJTtYwV/d0CsvcXycgLzD8sytCbShNkr2NBcXKPjy0J3 Xr8g== X-Forwarded-Encrypted: i=1; AKwUvBxUXt65O7jN8sh/Bvr0l5jsHCjuAFNp9qzwQ52GagXeLD4yyZjm2XAD1SgWsMw6eNIJ/Q1OaBxMT1xEzQ==@sourceware.org X-Gm-Message-State: AFuF++nTHQ1GRZN9bdVkirZeX7CfFb4HdspAvjIFqvHPHpf4Qw+f3bKK 899ugPmPTxej+zOz49IN0IaeryscZ3XwMw2UBMD0iQonFYQ9QJjNuJvUOgxaunCDIXAdinzkurD uCiG8tGmCh1ngAedXBOsTdn+weClsx4HDa4LyjTnoBIZG2rjVdo96/D4oJNkf0054HnYEXRA= X-Gm-Gg: AYBFou1zF/G1wIm2+4/B5W5k+qEk39euht11gNAzW1T3AiICZX5YotoNVZ+g/dpkRoH yFGEK1Y9sZhCCZpmAKQzp32uCMfrgz0OPDT7XVk4Jv4fIPQiDIPqafxyGXOagin7mzXVEaQ78SX 3m6Lj7OTLWw4L7+WLtul2OYjAJEo0LTIYfp7NUKjYjiv0VSPB3SC97mR2m76BoaIxBbMLi2SD4u 5QBRs4A5sJUirXlqi+2PvfItPS9OXOKLoNAiWU8aBFMFIbYqDlsO5misV5C0Jnnb8SpXbTVQGTJ 1R+o71sVsFLLre8miYBCnkS8Yy2kgvtMo7bJwbPTQF1fCV7xCEG2mciVlT3zan8JEn5+OrwOHe1 Zen6W1+yyzFUCxnILjvVTGntIf6s= X-Received: by 2002:a05:6000:605:b0:485:8c16:a360 with SMTP id ffacd0b85a97d-4858c16a6abmr3371456f8f.56.1788527307318; Fri, 04 Sep 2026 06:08:27 -0700 (PDT) X-Received: by 2002:a05:6000:605:b0:485:8c16:a360 with SMTP id ffacd0b85a97d-4858c16a6abmr3364984f8f.56.1788527255297; Fri, 04 Sep 2026 06:07:35 -0700 (PDT) Received: from localhost (128.223.159.143.dyn.plus.net. [143.159.223.128]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883959f0sm6706154f8f.10.2026.09.04.06.07.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 06:07:34 -0700 (PDT) From: Andrew Burgess To: Tom de Vries , gdb-patches@sourceware.org Subject: Re: [RFC] [gdb] Work around zero l_addr/l_ld In-Reply-To: <20260818071434.2121734-1-tdevries@suse.de> References: <20260818071434.2121734-1-tdevries@suse.de> Date: Fri, 04 Sep 2026 14:07:34 +0100 Message-ID: <87ecf9rwq1.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: _uKmFcpQK7r6dmMSInJC4jxEZmm0Ra4xNu78U0wEehU_1788527368 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 Tom de Vries writes: > 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") > - 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 replicating the missing glibc commit in > svr4_solib_ops::read_lm_info. > > I've enabled the fix only for the configuration I can test, for all others I > disabled it using "lmo.l_real_offset = -1". > > This is an RFC. My question is: is the added complexity worth the trouble for > what looks like a cornercase? My take on this would be no, it's not worth the complexity. It sounds like the problem is caused by a glibc that has back-ported one part of a fix, but missed the second part. I would suggest that a better solution would be to raise a bug against the downstream glibc port and get them to back-port the second part of the fix (commit 88361b408b). Thanks, Andrew