This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] malloc: Use compat_symbol_reference in libmcheck [BZ #22050]

On 08/31/2017 05:23 PM, Carlos O'Donell wrote:

> We deprecated __malloc_initialize_hook in There is only a compat
> symbol there, which can only be interposed by a definition of the same version.
> In libmcheck.a we have __malloc_initialize_hook (unversioned) which no longer
> interposes the symbol in (it would have interposed the default if
> there was one).
> So what does the compat_symbol_reference create in the libmcheck.a? An undefined
> reference to __malloc_initialize_hook@GLIBC_2_0?

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.

The existing libmcheck.a works if you link the main program with
--export-dynamic or otherwise arrange for an exported
__malloc_initialize_hook (even unversioned).

What happens with my patch is that the definition has the proper symbol
version, so the link editor matches it against the definition in
and notices that it needs to be listed in .dynsym.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]