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

[Daniel Walker]

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