From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by sourceware.org (Postfix) with ESMTPS id CAED33848401 for ; Wed, 28 Jul 2021 15:44:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CAED33848401 X-IronPort-AV: E=Sophos;i="5.84,276,1620691200"; d="scan'208";a="645533664" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jul 2021 15:44:10 +0000 Received: from zorba ([10.24.27.66]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 16SFi821013498 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Jul 2021 15:44:09 GMT Date: Wed, 28 Jul 2021 08:44:08 -0700 From: Daniel Walker To: "H.J. Lu" Cc: Florian Weimer , "Metzger, Markus T" , "Carlos O'Donell via Libc-alpha" , Pedro Alves , Conan C Huang , Florian Weimer , Jeremy Stenglein , xe-linux-external@cisco.com Subject: Re: [RFC PATCH 3/3] add r_debug multiple namespaces support Message-ID: <20210728154408.GF1633923@zorba> References: <210c992f-b034-3ef7-440c-f67ab1b3acdb@redhat.com> <87366h5xmi.fsf@oldenburg2.str.redhat.com> <7e2fb426-cf03-a8e7-6524-a5f81fcf5b9e@redhat.com> <87ftagyhra.fsf@mid.deneb.enyo.de> <8a15bd93-e4cc-a3bc-f902-5b3e701ec4e3@redhat.com> <87y2o61chx.fsf@oldenburg2.str.redhat.com> <20210727173958.GB1633923@zorba> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Auto-Response-Suppress: DR, OOF, AutoReply X-Outbound-SMTP-Client: 10.24.27.66, [10.24.27.66] X-Outbound-Node: rcdn-core-2.cisco.com X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 15:44:13 -0000 On Wed, Jul 28, 2021 at 08:15:10AM -0700, H.J. Lu wrote: > On Tue, Jul 27, 2021 at 11:14 AM H.J. Lu wrote: > > > > On Tue, Jul 27, 2021 at 10:40 AM Daniel Walker wrote: > > > > > > On Fri, Jul 23, 2021 at 04:38:33PM -0700, H.J. Lu wrote: > > > > On Mon, Jun 29, 2020 at 2:49 AM Florian Weimer via Libc-alpha > > > > wrote: > > > > > > > > > > * Carlos O'Donell via Libc-alpha: > > > > > > > > > > >>> I'm not sure it would work to version _r_debug, since the debugger > > > > > >>> is using DT_DEBUG and we only get to put one value in that > > > > > >>> .dynamic entry. > > > > > >> > > > > > >> The symbol version is needed to avoid problems due to copy relocations > > > > > >> if the symbol is referenced directly from the main program. Without > > > > > >> that, the object could be truncated. It's not a debugger > > > > > >> compatibility feature. > > > > > > > > > > > > Correct, but this violates *how* you're supposed to use _r_debug. > > > > > > > > > > If it is possible to link against it, we need to add the new symbol > > > > > version, in my opinion. > > > > > > > > > > > In the dynamic case it is different. The symbol should be looked up > > > > > > via DT_DEBUG only which always points to the library-local address > > > > > > of the data object (and the most recent version). In effect this > > > > > > bypasses the COPY relocation? > > > > > > > > > > How is this supposed to work if the dynamic linker does contain > > > > > DT_DEBUG? > > > > > > > > > > I only observe DT_DEBUG in PIE binaries, but since the dynamic loader is > > > > > mapped at a random address even for ET_EXEC main programs, there must be > > > > > some other mechanism to locate it. > > > > > > > > > > Thanks, > > > > > Florian > > > > > > > > > > > > > I opened: > > > > > > > > https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2 > > > > > > > > with a proposal to extend struct r_debug for libraries loaded with > > > > dlmopen, I'd like to resolve it for the next releases of glibc, binutils > > > > and GDB. > > > > > > > > > I have an updated set of changes which add a new dynamic entry > > > DT_DEBUG_DLMOPEN, which was recommended by Carlos. We're still testing the > > > implementation. I'm open to support different implementations. > > Please send an email to gABI group: > > https://groups.google.com/g/generic-abi > > to add a new DT_XXX. If it is impractical to add a new DT_XXX to gABI, > I propose DT_GNU_DEBUG: > > https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2 > > to cover dlmopen and beyond. > The last time this was discussed I thought this was the gABI group. Someone had said gABI was getting taken over by glibc. Daniel