[RFC,3/3] add r_debug multiple namespaces support

  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(-)
  

* 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