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

[Daniel Walker (danielwa)]

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