This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: Use compat_symbol_reference in libmcheck [BZ #22050]
On Thu, 31 Aug 2017, Florian Weimer wrote:
> On 08/31/2017 06:02 PM, Joseph Myers wrote:
> > On Thu, 31 Aug 2017, Florian Weimer wrote:
> >
> >> Interposition happens only if __malloc_initialize_hook is listed in the
> >> .dynsym section of the executable. At least some versions of binutils
> >> will not add the symbol to the .dynsym section if it is unversioned and
> >> there is a definition in a DSO which lacks a default version. Arguably
> >> this is a bug in the link editor.
> >
> > Sounds like a feature to me, not a bug. After all, it's essentially what
> > makes it possible for us to obsolete (stop working for new programs as far
> > as possible) symbols whose interface is that the program interposes them,
> > such as matherr. Effectively, a DSO definition that lacks a default
> > version should be treated exactly the same at static link time as no DSO
> > definition at all.
>
> But that's not what happens if you compile with --export-dynamic. That
> --export-dynamic changes behavior here is very surprising. That's why I
> think this could be considered a bug in the link editor.
That --export-dynamic changes things sounds like a consequence of the rule
that an unversioned symbol can be linked to the base symbol version,
because symbol versioning support wasn't added until glibc 2.1 and
binaries with unversioned references to glibc 2.0 symbols needed to be
supported. I'm not sure how to fix that (stop --export-dynamic allowing
symbols to link to compat symbols) - maybe that special rule should be
disabled for glibc symbols if a program has any dependence on a glibc
version greater than 2.0, is there a way we can make sure all newly linked
programs have such dependence to stop that rule applying to them? (If
--export-dynamic results in *versioned* exports from the executable for
such symbols as matherr or __malloc_initialize_hook, that sounds like a
bug in ld.)
--
Joseph S. Myers
joseph@codesourcery.com