Message ID | 20200626193228.1953-4-danielwa@cisco.com |
---|---|
State | New, archived |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F11BB388C03C; Fri, 26 Jun 2020 19:32:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F11BB388C03C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1593199962; bh=mbYCkopn2k6PydWBW01day3Wie0S7QcfTbkcMurogpo=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=UqVh7Fv9SWVytOQ0d5qtcAuSRKP4WGPRRMDfCB1dhhhKHA4OO8RZZiqKkqAkudx5x 8Xs2v+gV4wu3OsdKdH0dp42iOGfBsbZvI9pzCuvxcj0phl/FMiHq8aN/nRcU7Li3PR XLOc9Z6u1EmtCj14UTb2qHkwJmdOBLNGG2G9syOU= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by sourceware.org (Postfix) with ESMTPS id 16C66386F83E for <libc-alpha@sourceware.org>; Fri, 26 Jun 2020 19:32:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 16C66386F83E X-IronPort-AV: E=Sophos;i="5.75,282,1589241600"; d="scan'208";a="528276816" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jun 2020 19:32:34 +0000 Received: from zorba.cisco.com ([10.24.15.228]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTP id 05QJWSW6030756; Fri, 26 Jun 2020 19:32:30 GMT To: libc-alpha@sourceware.org Subject: [RFC PATCH 3/3] add r_debug multiple namespaces support Date: Fri, 26 Jun 2020 12:32:28 -0700 Message-Id: <20200626193228.1953-4-danielwa@cisco.com> X-Mailer: git-send-email 2.17.1 X-Auto-Response-Suppress: DR, OOF, AutoReply X-Outbound-SMTP-Client: 10.24.15.228, [10.24.15.228] X-Outbound-Node: alln-core-8.cisco.com X-Spam-Status: No, score=-17.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <http://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <http://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Daniel Walker via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Daniel Walker <danielwa@cisco.com> Cc: Conan C Huang <conhuang@cisco.com>, Jeremy Stenglein <jstengle@cisco.com>, xe-linux-external@cisco.com Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
implement dlmopen hooks for gdb
|
|
Commit Message
Daniel Walker
June 26, 2020, 7:32 p.m. UTC
From: Conan C Huang <conhuang@cisco.com>
GLIBC Bugzilla: 15971
GDB Bugzilla: 11839
Glibc does not provide an interface for debugger to access libraries loaded in
multiple namespaces via dlmopen.
The current rtld-debugger interface is described in the file
elf/rtld-debugger-interface.txt under the "Standard debugger interface" heading.
This interface only provides access to the first link-map (LM_ID_BASE).
This solution converts r_debug into a linked-list, where each element correlates
to an unique namespace. Debugger (GDB) can traverse r_debug linked-list to
retrieve information for all loaded namespaces.
---
elf/dl-debug.c | 13 ++++++++++---
elf/link.h | 4 ++++
2 files changed, 14 insertions(+), 3 deletions(-)
Comments
* Daniel Walker via Libc-alpha: > diff --git a/elf/link.h b/elf/link.h > index 0048ad5d4d..5a42511636 100644 > --- a/elf/link.h > +++ b/elf/link.h > @@ -61,6 +61,10 @@ struct r_debug > } r_state; > > ElfW(Addr) r_ldbase; /* Base address the linker is loaded at. */ > + > + /* Link to next r_debug struct. Each r_debug struct represents a > + different namespace. The first r_debug struct is the default. */ > + struct r_debug *next; > }; > > /* This is the instance of that structure used by the dynamic linker. */ How has this patch been tested? I expect that it will cause an abilist mismatch for the _r_debug symbol in the dynamic linker. If we go this route to add this capability, I think we have to add a new symbol version for the _r_debug symbol, and keep the old one at the previous size. How is your compatibility experience with the size and version change? How many tools need updating before they work again? A different approach would add another symbol (parallel to _r_debug) to store this data. This would avoid the need for any immediate tool updates. Thanks, Florian
On 6/26/20 5:05 PM, Florian Weimer via Libc-alpha wrote: > * Daniel Walker via Libc-alpha: > >> diff --git a/elf/link.h b/elf/link.h >> index 0048ad5d4d..5a42511636 100644 >> --- a/elf/link.h >> +++ b/elf/link.h >> @@ -61,6 +61,10 @@ struct r_debug >> } r_state; >> >> ElfW(Addr) r_ldbase; /* Base address the linker is loaded at. */ >> + >> + /* Link to next r_debug struct. Each r_debug struct represents a >> + different namespace. The first r_debug struct is the default. */ >> + struct r_debug *next; >> }; >> >> /* This is the instance of that structure used by the dynamic linker. */ > > How has this patch been tested? I expect that it will cause an abilist > mismatch for the _r_debug symbol in the dynamic linker. > > If we go this route to add this capability, I think we have to add a new > symbol version for the _r_debug symbol, and keep the old one at the > previous size. > > How is your compatibility experience with the size and version change? > How many tools need updating before they work again? > > A different approach would add another symbol (parallel to _r_debug) to > store this data. This would avoid the need for any immediate tool > updates. I mention this in my response to the cover letter in this series. This patch is probably unacceptable as-is because of application expectations.
* Carlos O'Donell: > On 6/26/20 5:05 PM, Florian Weimer via Libc-alpha wrote: >> * Daniel Walker via Libc-alpha: >> >>> diff --git a/elf/link.h b/elf/link.h >>> index 0048ad5d4d..5a42511636 100644 >>> --- a/elf/link.h >>> +++ b/elf/link.h >>> @@ -61,6 +61,10 @@ struct r_debug >>> } r_state; >>> >>> ElfW(Addr) r_ldbase; /* Base address the linker is loaded at. */ >>> + >>> + /* Link to next r_debug struct. Each r_debug struct represents a >>> + different namespace. The first r_debug struct is the default. */ >>> + struct r_debug *next; >>> }; >>> >>> /* This is the instance of that structure used by the dynamic linker. */ >> >> How has this patch been tested? I expect that it will cause an abilist >> mismatch for the _r_debug symbol in the dynamic linker. >> >> If we go this route to add this capability, I think we have to add a new >> symbol version for the _r_debug symbol, and keep the old one at the >> previous size. >> >> How is your compatibility experience with the size and version change? >> How many tools need updating before they work again? >> >> A different approach would add another symbol (parallel to _r_debug) to >> store this data. This would avoid the need for any immediate tool >> updates. > > I mention this in my response to the cover letter in this series. Your explanation there was truncated. > This patch is probably unacceptable as-is because of application > expectations. But perhaps Cisco's experience shows that our worries are unfounded? Thanks, Florian
On 6/26/20 5:24 PM, Florian Weimer wrote: > * Carlos O'Donell: > >> On 6/26/20 5:05 PM, Florian Weimer via Libc-alpha wrote: >>> * Daniel Walker via Libc-alpha: >>> >>>> diff --git a/elf/link.h b/elf/link.h >>>> index 0048ad5d4d..5a42511636 100644 >>>> --- a/elf/link.h >>>> +++ b/elf/link.h >>>> @@ -61,6 +61,10 @@ struct r_debug >>>> } r_state; >>>> >>>> ElfW(Addr) r_ldbase; /* Base address the linker is loaded at. */ >>>> + >>>> + /* Link to next r_debug struct. Each r_debug struct represents a >>>> + different namespace. The first r_debug struct is the default. */ >>>> + struct r_debug *next; >>>> }; >>>> >>>> /* This is the instance of that structure used by the dynamic linker. */ >>> >>> How has this patch been tested? I expect that it will cause an abilist >>> mismatch for the _r_debug symbol in the dynamic linker. >>> >>> If we go this route to add this capability, I think we have to add a new >>> symbol version for the _r_debug symbol, and keep the old one at the >>> previous size. >>> >>> How is your compatibility experience with the size and version change? >>> How many tools need updating before they work again? >>> >>> A different approach would add another symbol (parallel to _r_debug) to >>> store this data. This would avoid the need for any immediate tool >>> updates. >> >> I mention this in my response to the cover letter in this series. > > Your explanation there was truncated. Truncated in which way? >> This patch is probably unacceptable as-is because of application >> expectations. > > But perhaps Cisco's experience shows that our worries are unfounded? That would be great! I would want to see gdb changed to r_version > 0, and document that the increasing r_version means changes that only expand the structure and add new information while keeping old information backwards compatible. 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.
On Fri, Jun 26, 2020 at 11:24:21PM +0200, Florian Weimer wrote: > * Carlos O'Donell: > > > On 6/26/20 5:05 PM, Florian Weimer via Libc-alpha wrote: > >> * Daniel Walker via Libc-alpha: > >> > >>> diff --git a/elf/link.h b/elf/link.h > >>> index 0048ad5d4d..5a42511636 100644 > >>> --- a/elf/link.h > >>> +++ b/elf/link.h > >>> @@ -61,6 +61,10 @@ struct r_debug > >>> } r_state; > >>> > >>> ElfW(Addr) r_ldbase; /* Base address the linker is loaded at. */ > >>> + > >>> + /* Link to next r_debug struct. Each r_debug struct represents a > >>> + different namespace. The first r_debug struct is the default. */ > >>> + struct r_debug *next; > >>> }; > >>> > >>> /* This is the instance of that structure used by the dynamic linker. */ > >> > >> How has this patch been tested? I expect that it will cause an abilist > >> mismatch for the _r_debug symbol in the dynamic linker. > >> > >> If we go this route to add this capability, I think we have to add a new > >> symbol version for the _r_debug symbol, and keep the old one at the > >> previous size. > >> > >> How is your compatibility experience with the size and version change? > >> How many tools need updating before they work again? > >> > >> A different approach would add another symbol (parallel to _r_debug) to > >> store this data. This would avoid the need for any immediate tool > >> updates. > > > > I mention this in my response to the cover letter in this series. > > Your explanation there was truncated. > > > This patch is probably unacceptable as-is because of application > > expectations. > > But perhaps Cisco's experience shows that our worries are unfounded? I don't know that we can confirm this. Per my understanding these changes have been maintained as one off changes which haven't entered our product yet. We're now currently trying to add this to our product. We use OpenEmbedded to build an SDK which is then used in our product. The tooling in typical rebuilt against any new glibc which we have, and we don't reuse binaries from the prior builds which may have a different glibc (even different patch level). Daniel
* Carlos O'Donell via Libc-alpha: > Truncated in which way? This part: | Your proposed solution of bumping the version is unacceptable, | and was last rejected by Roland McGrath. The problem is that | when you bump the version the current > 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.
On 6/27/20 5:34 AM, Florian Weimer wrote: > * Carlos O'Donell via Libc-alpha: > >> Truncated in which way? > > This part: > > | Your proposed solution of bumping the version is unacceptable, > | and was last rejected by Roland McGrath. The problem is that > | when you bump the version the current Thanks. "It's Friday" is my only excuse. I did provide some of the original links to the discussion. Roland, as a steward at the time, was worried about exactly what we see in gdb, which is "r_version != 1" may have made it into tooling. We can test this. We can try to deploy a similar solution in Fedora Rawhide and declare the semantics as we expect them to be. That is to say that r_version == 1, is the entire structure as we have it, and r_version == 2 *adds* but does not remove from the structure. Since the data is maintained by the implementation and the caller is only inspecting the data it should work. >> 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 you have a static executable you can get away with referencing _r_debug directly, but in that case symbol versions don't matter, and you have whatever version you have at the time. 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? If an application uses _r_debug, the symbol, directly, then they should get a static copy via the COPY relocation, and it will not be updated after that. Perhaps we can arrange for such an initial _r_debug to indicate it's not active or initialized? IMO the library should use a local-only reference to the _r_debug to avoid going through the global reference. I'm not keen to admit that a COPY reloc of _r_debug should work.
* 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
On Mon, Jun 29, 2020 at 2:49 AM Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> 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.
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 > <libc-alpha@sourceware.org> 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. I found while working on this project that the clang linker adds 3 proprietary new dynamic entries. So there is demand to make adding to the table easier. Daniel
On Tue, Jul 27, 2021 at 10:40 AM Daniel Walker <danielwa@cisco.com> 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 > > <libc-alpha@sourceware.org> 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. Let's work on it after glibc 2.34 is branched. > I found while working on this project that the clang linker adds 3 proprietary new > dynamic entries. So there is demand to make adding to the table easier. > > Daniel
On Tue, Jul 27, 2021 at 11:14 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Tue, Jul 27, 2021 at 10:40 AM Daniel Walker <danielwa@cisco.com> 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 > > > <libc-alpha@sourceware.org> 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. > Let's work on it after glibc 2.34 is branched. > > > I found while working on this project that the clang linker adds 3 proprietary new > > dynamic entries. So there is demand to make adding to the table easier. > > > > Daniel > > > > -- > H.J.
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 <hjl.tools@gmail.com> wrote: > > > > On Tue, Jul 27, 2021 at 10:40 AM Daniel Walker <danielwa@cisco.com> 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 > > > > <libc-alpha@sourceware.org> 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
On Wed, Jul 28, 2021 at 8:44 AM Daniel Walker <danielwa@cisco.com> wrote: > > 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 <hjl.tools@gmail.com> wrote: > > > > > > On Tue, Jul 27, 2021 at 10:40 AM Daniel Walker <danielwa@cisco.com> 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 > > > > > <libc-alpha@sourceware.org> 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. There are 2 gABI groups: 1. OS independent gABI: https://groups.google.com/g/generic-abi 2. Linux/GNU specific extensions to gABI: https://sourceware.org/mailman/listinfo/gnu-gabi We can try #1 first.
On Wed, Jul 28, 2021 at 10:14:41AM -0700, H.J. Lu wrote: > On Wed, Jul 28, 2021 at 8:44 AM Daniel Walker <danielwa@cisco.com> wrote: > > > > 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 <hjl.tools@gmail.com> wrote: > > > > > > > > On Tue, Jul 27, 2021 at 10:40 AM Daniel Walker <danielwa@cisco.com> 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 > > > > > > <libc-alpha@sourceware.org> 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. > > There are 2 gABI groups: > > 1. OS independent gABI: > > https://groups.google.com/g/generic-abi > > 2. Linux/GNU specific extensions to gABI: > > https://sourceware.org/mailman/listinfo/gnu-gabi > > We can try #1 first. Do you want to drive this, or should I ? It looks like you know the people involved better than I do. Daniel
On Wed, Jul 28, 2021 at 12:02 PM Daniel Walker <danielwa@cisco.com> wrote: > > On Wed, Jul 28, 2021 at 10:14:41AM -0700, H.J. Lu wrote: > > On Wed, Jul 28, 2021 at 8:44 AM Daniel Walker <danielwa@cisco.com> wrote: > > > > > > 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 <hjl.tools@gmail.com> wrote: > > > > > > > > > > On Tue, Jul 27, 2021 at 10:40 AM Daniel Walker <danielwa@cisco.com> 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 > > > > > > > <libc-alpha@sourceware.org> 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. > > > > There are 2 gABI groups: > > > > 1. OS independent gABI: > > > > https://groups.google.com/g/generic-abi > > > > 2. Linux/GNU specific extensions to gABI: > > > > https://sourceware.org/mailman/listinfo/gnu-gabi > > > > We can try #1 first. > > Do you want to drive this, or should I ? It looks like you know the people > involved better than I do. > https://groups.google.com/g/generic-abi/c/1ngxmSwrafc
On Wed, Jul 28, 2021 at 1:04 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > Do you want to drive this, or should I ? It looks like you know the people > > involved better than I do. > > > > https://groups.google.com/g/generic-abi/c/1ngxmSwrafc > I don't think the gABI community is interested in a new debug dynamic tag. I propose DT_GNU_DEBUG: #define DT_GNU_DEBUG 0x6ffffff8 for the address of a pointer which will be filled by the dynamic linker. Linker should add the DT_GNU_DEBUG entry to executable's dynamic section. BTW, we have a choice. DT_GNU_DEBUG can be readonly or readonly after relocation, like DT_DEBUG.
* H. J. Lu: > On Wed, Jul 28, 2021 at 1:04 PM H.J. Lu <hjl.tools@gmail.com> wrote: >> > Do you want to drive this, or should I ? It looks like you know the people >> > involved better than I do. >> > >> >> https://groups.google.com/g/generic-abi/c/1ngxmSwrafc >> > > I don't think the gABI community is interested in a new debug dynamic > tag. I propose DT_GNU_DEBUG: > > #define DT_GNU_DEBUG 0x6ffffff8 > > for the address of a pointer which will be filled by the dynamic > linker. Linker should > add the DT_GNU_DEBUG entry to executable's dynamic section. > > BTW, we have a choice. DT_GNU_DEBUG can be readonly or readonly after > relocation, like DT_DEBUG. What about adding DT_DEBUG_SIZE, specifying the size of the data pointed to by DT_DEBUG? Perhaps the gABI folks are interested in that, too? I think it's worth a try. If the answer is “no”, we can still add DT_GNU_DEBUG_SIZE to the GNU ABI. Thanks, Florian
On Sun, Aug 1, 2021 at 10:22 PM Florian Weimer <fweimer@redhat.com> wrote: > > * H. J. Lu: > > > On Wed, Jul 28, 2021 at 1:04 PM H.J. Lu <hjl.tools@gmail.com> wrote: > >> > Do you want to drive this, or should I ? It looks like you know the people > >> > involved better than I do. > >> > > >> > >> https://groups.google.com/g/generic-abi/c/1ngxmSwrafc > >> > > > > I don't think the gABI community is interested in a new debug dynamic > > tag. I propose DT_GNU_DEBUG: > > > > #define DT_GNU_DEBUG 0x6ffffff8 > > > > for the address of a pointer which will be filled by the dynamic > > linker. Linker should > > add the DT_GNU_DEBUG entry to executable's dynamic section. > > > > BTW, we have a choice. DT_GNU_DEBUG can be readonly or readonly after > > relocation, like DT_DEBUG. > > What about adding DT_DEBUG_SIZE, specifying the size of the data pointed > to by DT_DEBUG? It works if we don't need to support static executables. > Perhaps the gABI folks are interested in that, too? I think it's worth > a try. If the answer is “no”, we can still add DT_GNU_DEBUG_SIZE to the > GNU ABI. I did. I didn't get any feedback.
On Mon, Aug 02, 2021 at 06:10:55AM -0700, H.J. Lu wrote: > On Sun, Aug 1, 2021 at 10:22 PM Florian Weimer <fweimer@redhat.com> wrote: > > > > * H. J. Lu: > > > > > On Wed, Jul 28, 2021 at 1:04 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > >> > Do you want to drive this, or should I ? It looks like you know the people > > >> > involved better than I do. > > >> > > > >> > > >> https://groups.google.com/g/generic-abi/c/1ngxmSwrafc > > >> > > > > > > I don't think the gABI community is interested in a new debug dynamic > > > tag. I propose DT_GNU_DEBUG: > > > > > > #define DT_GNU_DEBUG 0x6ffffff8 > > > > > > for the address of a pointer which will be filled by the dynamic > > > linker. Linker should > > > add the DT_GNU_DEBUG entry to executable's dynamic section. > > > > > > BTW, we have a choice. DT_GNU_DEBUG can be readonly or readonly after > > > relocation, like DT_DEBUG. > > > > What about adding DT_DEBUG_SIZE, specifying the size of the data pointed > > to by DT_DEBUG? > > It works if we don't need to support static executables. > > > Perhaps the gABI folks are interested in that, too? I think it's worth > > a try. If the answer is “no”, we can still add DT_GNU_DEBUG_SIZE to the > > GNU ABI. > > I did. I didn't get any feedback. So no feedback equal "not interested" ? Daniel
On Tue, Aug 3, 2021 at 9:39 AM Daniel Walker <danielwa@cisco.com> wrote: > > On Mon, Aug 02, 2021 at 06:10:55AM -0700, H.J. Lu wrote: > > On Sun, Aug 1, 2021 at 10:22 PM Florian Weimer <fweimer@redhat.com> wrote: > > > > > > * H. J. Lu: > > > > > > > On Wed, Jul 28, 2021 at 1:04 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > >> > Do you want to drive this, or should I ? It looks like you know the people > > > >> > involved better than I do. > > > >> > > > > >> > > > >> https://groups.google.com/g/generic-abi/c/1ngxmSwrafc > > > >> > > > > > > > > I don't think the gABI community is interested in a new debug dynamic > > > > tag. I propose DT_GNU_DEBUG: > > > > > > > > #define DT_GNU_DEBUG 0x6ffffff8 > > > > > > > > for the address of a pointer which will be filled by the dynamic > > > > linker. Linker should > > > > add the DT_GNU_DEBUG entry to executable's dynamic section. > > > > > > > > BTW, we have a choice. DT_GNU_DEBUG can be readonly or readonly after > > > > relocation, like DT_DEBUG. > > > > > > What about adding DT_DEBUG_SIZE, specifying the size of the data pointed > > > to by DT_DEBUG? > > > > It works if we don't need to support static executables. Given that we export _r_debug and some programs, like GNAT, use it, we should keep and fix _r_debug. We should also make the new interface available for these programs and include the structure size in the new interface. > > > > > Perhaps the gABI folks are interested in that, too? I think it's worth > > > a try. If the answer is “no”, we can still add DT_GNU_DEBUG_SIZE to the > > > GNU ABI. > > > > I did. I didn't get any feedback. > > So no feedback equal "not interested" ? I'd like to resolve this issue for glibc 2.35. We need to move forward with a new DT_XXX. We can't wait too long.
* Daniel Walker: > On Mon, Aug 02, 2021 at 06:10:55AM -0700, H.J. Lu wrote: >> On Sun, Aug 1, 2021 at 10:22 PM Florian Weimer <fweimer@redhat.com> wrote: >> > >> > * H. J. Lu: >> > >> > > On Wed, Jul 28, 2021 at 1:04 PM H.J. Lu <hjl.tools@gmail.com> wrote: >> > >> > Do you want to drive this, or should I ? It looks like you know the people >> > >> > involved better than I do. >> > >> > >> > >> >> > >> https://groups.google.com/g/generic-abi/c/1ngxmSwrafc >> > >> >> > > >> > > I don't think the gABI community is interested in a new debug dynamic >> > > tag. I propose DT_GNU_DEBUG: >> > > >> > > #define DT_GNU_DEBUG 0x6ffffff8 >> > > >> > > for the address of a pointer which will be filled by the dynamic >> > > linker. Linker should >> > > add the DT_GNU_DEBUG entry to executable's dynamic section. >> > > >> > > BTW, we have a choice. DT_GNU_DEBUG can be readonly or readonly after >> > > relocation, like DT_DEBUG. >> > >> > What about adding DT_DEBUG_SIZE, specifying the size of the data pointed >> > to by DT_DEBUG? >> >> It works if we don't need to support static executables. >> >> > Perhaps the gABI folks are interested in that, too? I think it's worth >> > a try. If the answer is “no”, we can still add DT_GNU_DEBUG_SIZE to the >> > GNU ABI. >> >> I did. I didn't get any feedback. > > So no feedback equal "not interested" ? I think the issue is that the struct already has a version field. It's only a problem for us because we have architectures with copy relocations *and* have exposed _r_debug as a public symbol. However, we can do what we did for _sys_errlist in the past (new symbol versions for each size change), so it's not a real blocker. I suppose the easiest way forward would be to grow _r_debug this way, bump the version field past Solaris' version, add the Solaris members (possibly with dummy values), and add our own new stuff afterwards. Thanks, Florian
On Tue, Aug 3, 2021 at 11:12 AM Florian Weimer <fweimer@redhat.com> wrote: > > * Daniel Walker: > > > On Mon, Aug 02, 2021 at 06:10:55AM -0700, H.J. Lu wrote: > >> On Sun, Aug 1, 2021 at 10:22 PM Florian Weimer <fweimer@redhat.com> wrote: > >> > > >> > * H. J. Lu: > >> > > >> > > On Wed, Jul 28, 2021 at 1:04 PM H.J. Lu <hjl.tools@gmail.com> wrote: > >> > >> > Do you want to drive this, or should I ? It looks like you know the people > >> > >> > involved better than I do. > >> > >> > > >> > >> > >> > >> https://groups.google.com/g/generic-abi/c/1ngxmSwrafc > >> > >> > >> > > > >> > > I don't think the gABI community is interested in a new debug dynamic > >> > > tag. I propose DT_GNU_DEBUG: > >> > > > >> > > #define DT_GNU_DEBUG 0x6ffffff8 > >> > > > >> > > for the address of a pointer which will be filled by the dynamic > >> > > linker. Linker should > >> > > add the DT_GNU_DEBUG entry to executable's dynamic section. > >> > > > >> > > BTW, we have a choice. DT_GNU_DEBUG can be readonly or readonly after > >> > > relocation, like DT_DEBUG. > >> > > >> > What about adding DT_DEBUG_SIZE, specifying the size of the data pointed > >> > to by DT_DEBUG? > >> > >> It works if we don't need to support static executables. > >> > >> > Perhaps the gABI folks are interested in that, too? I think it's worth > >> > a try. If the answer is “no”, we can still add DT_GNU_DEBUG_SIZE to the > >> > GNU ABI. > >> > >> I did. I didn't get any feedback. > > > > So no feedback equal "not interested" ? > > I think the issue is that the struct already has a version field. > > It's only a problem for us because we have architectures with copy > relocations *and* have exposed _r_debug as a public symbol. However, we > can do what we did for _sys_errlist in the past (new symbol versions for > each size change), so it's not a real blocker. No, copy relocation doesn't work: https://sourceware.org/bugzilla/show_bug.cgi?id=28130 I want to get rid of copy relocation and keep _r_debug only for existing broken binaries. The new interface will provide an access function to get the address of internal data in ld.so. > I suppose the easiest way forward would be to grow _r_debug this way, > bump the version field past Solaris' version, add the Solaris members > (possibly with dummy values), and add our own new stuff afterwards. > > Thanks, > Florian >
On Tue, Aug 03, 2021 at 11:08:35AM -0700, H.J. Lu wrote: > On Tue, Aug 3, 2021 at 9:39 AM Daniel Walker <danielwa@cisco.com> wrote: > > > > On Mon, Aug 02, 2021 at 06:10:55AM -0700, H.J. Lu wrote: > > > On Sun, Aug 1, 2021 at 10:22 PM Florian Weimer <fweimer@redhat.com> wrote: > > > > > > > > * H. J. Lu: > > > > > > > > > On Wed, Jul 28, 2021 at 1:04 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > >> > Do you want to drive this, or should I ? It looks like you know the people > > > > >> > involved better than I do. > > > > >> > > > > > >> > > > > >> https://groups.google.com/g/generic-abi/c/1ngxmSwrafc > > > > >> > > > > > > > > > > I don't think the gABI community is interested in a new debug dynamic > > > > > tag. I propose DT_GNU_DEBUG: > > > > > > > > > > #define DT_GNU_DEBUG 0x6ffffff8 > > > > > > > > > > for the address of a pointer which will be filled by the dynamic > > > > > linker. Linker should > > > > > add the DT_GNU_DEBUG entry to executable's dynamic section. > > > > > > > > > > BTW, we have a choice. DT_GNU_DEBUG can be readonly or readonly after > > > > > relocation, like DT_DEBUG. > > > > > > > > What about adding DT_DEBUG_SIZE, specifying the size of the data pointed > > > > to by DT_DEBUG? > > > > > > It works if we don't need to support static executables. > > Given that we export _r_debug and some programs, like GNAT, use it, > we should keep and fix _r_debug. We should also make the new interface > available for these programs and include the structure size in the new > interface. > > > > > > > > Perhaps the gABI folks are interested in that, too? I think it's worth > > > > a try. If the answer is “no”, we can still add DT_GNU_DEBUG_SIZE to the > > > > GNU ABI. > > > > > > I did. I didn't get any feedback. > > > > So no feedback equal "not interested" ? > > I'd like to resolve this issue for glibc 2.35. We need to move forward with > a new DT_XXX. We can't wait too long. What sort of response are you specifically looking for ? Daniel
* H. J. Lu: > No, copy relocation doesn't work: > > https://sourceware.org/bugzilla/show_bug.cgi?id=28130 > > I want to get rid of copy relocation and keep _r_debug only for existing > broken binaries. The new interface will provide an access function to > get the address of internal data in ld.so. Surely we can update both copies?! They exist today, so I don't expect new problems from a tools perspective. Thanks, Florian
On Tue, Aug 3, 2021 at 1:13 PM Florian Weimer <fweimer@redhat.com> wrote: > > * H. J. Lu: > > > No, copy relocation doesn't work: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=28130 > > > > I want to get rid of copy relocation and keep _r_debug only for existing > > broken binaries. The new interface will provide an access function to > > get the address of internal data in ld.so. > > Surely we can update both copies?! They exist today, so I don't expect > new problems from a tools perspective. > Why should we do that? We don't do that for errno.
We need a new DT_XXX to support dlmopen. We have 2 choices: 1. Similar to DT_DEBUG. Linker will allocate a new DT_XXX and ld.so will fill it with the address of the new debug data structure for dlmopen. 2. Similar to DT_MIPS_RLD_MAP_REL/DT_MIPS_RLD_MAP. Linker will allocate a space for a pointer, a new DT_XXX and fill the DT_XXX entry with the address of the pointer. ld.so will update the pointer with the address of the new debug data structure for dlmopen. #1 is the most straightforward to implement. #2 is compatible with the current MIPS implementation. Does anyone have any preferences?
On Mon, Aug 09, 2021 at 07:32:26AM -0700, H.J. Lu wrote: > We need a new DT_XXX to support dlmopen. We have 2 choices: > > 1. Similar to DT_DEBUG. Linker will allocate a new DT_XXX and > ld.so will fill it with the address of the new debug data structure for > dlmopen. > 2. Similar to DT_MIPS_RLD_MAP_REL/DT_MIPS_RLD_MAP. > Linker will allocate a space for a pointer, a new DT_XXX and fill > the DT_XXX entry with the address of the pointer. ld.so will update > the pointer with the address of the new debug data structure for > dlmopen. > > #1 is the most straightforward to implement. #2 is compatible with > the current MIPS implementation. > > Does anyone have any preferences? I have #1 fully implemented already. Daniel
diff --git a/elf/dl-debug.c b/elf/dl-debug.c index 4b3d3ad6ba..7eba477fd3 100644 --- a/elf/dl-debug.c +++ b/elf/dl-debug.c @@ -44,20 +44,27 @@ struct r_debug _r_debug; struct r_debug * _dl_debug_initialize (ElfW(Addr) ldbase, Lmid_t ns) { - struct r_debug *r; + struct r_debug *r, *rp; if (ns == LM_ID_BASE) r = &_r_debug; else - r = &GL(dl_ns)[ns]._ns_debug; + { + r = &GL(dl_ns)[ns]._ns_debug; + rp = &GL(dl_ns)[ns - 1]._ns_debug; + rp->next = r; + if (ns - 1 == LM_ID_BASE) + _r_debug.next = r; + } if (r->r_map == NULL || ldbase != 0) { /* Tell the debugger where to find the map of loaded objects. */ - r->r_version = 1 /* R_DEBUG_VERSION XXX */; + r->r_version = 3 /* R_DEBUG_VERSION XXX */; r->r_ldbase = ldbase ?: _r_debug.r_ldbase; r->r_map = (void *) GL(dl_ns)[ns]._ns_loaded; r->r_brk = (ElfW(Addr)) &_dl_debug_state; + r->next = NULL; } return r; diff --git a/elf/link.h b/elf/link.h index 0048ad5d4d..5a42511636 100644 --- a/elf/link.h +++ b/elf/link.h @@ -61,6 +61,10 @@ struct r_debug } r_state; ElfW(Addr) r_ldbase; /* Base address the linker is loaded at. */ + + /* Link to next r_debug struct. Each r_debug struct represents a + different namespace. The first r_debug struct is the default. */ + struct r_debug *next; }; /* This is the instance of that structure used by the dynamic linker. */