glibc 2.34 - Hard ABI freeze effective immediately.

H.J. Lu hjl.tools@gmail.com
Sun Jul 25 22:07:47 GMT 2021


On Sun, Jul 25, 2021 at 2:55 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu via Libc-alpha:
>
> > It was a mistake to export _r_debug from ld.so:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=28130
> >
> > I'd like to deprecate _r_debug in glibc 2.34 and replace it with:
> >
> > /* Return the address of that structure used by the dynamic linker.  */
> > extern struct r_debug * __r_debug_location (void) __attribute_const__;
> > #define _r_debug (*__r_debug_location ())
> >
> > so that I can extend struct r_debug for libraries loaded with dlmopen:
> >
> > https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2
>
> We need to keep it as a symbol because debuggers use it.

_r_debug is only needed in the static executable.  Debuggers should use
DT_DEBUG for dynamic executables.

> If GCC had a an attribute that says, no copy relocation please, we could
> perhaps use that in <link.h>.
>
> Maybe we can turn it into a compat symbol.  But it's too late for such

We can make it a compat symbol:

1. Add a function, __r_debug_location, which returns the address of
_r_debug:

/* Return the address of that structure used by the dynamic linker.  */
extern struct r_debug * __r_debug_location (void) __attribute_const__;

2. Hide _r_debug in ld.so by defining _r_debug with __r_debug_location:

 #define _r_debug (*__r_debug_location ())

The existing dynamic executables with _r_debug reference will get a copy
of _r_debug which won't be updated by ld.so.  But DT_DEBUG will work with
debuggers.
3. The static executables linked against glibc 2.34 will get the _r_debug
symbol from __r_debug_location definition in libc.a.

> changes in glibc 2.34.
>
> The replacement could use a separate symbol version (GLIBC_DEBUG) with
> different ABI stability rules, which would pave the way towards
> backporting.

There is no need for a special version symbol.   I have a proposal to make
it both forward and backward compatible.

-- 
H.J.


More information about the Libc-alpha mailing list