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

[Carlos O'Donell <carlos at redhat dot com>]

On 08/31/2017 10:28 AM, Florian Weimer wrote:
> On 08/31/2017 05:23 PM, Carlos O'Donell wrote:
> 
>> We deprecated __malloc_initialize_hook in libc.so.6. 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 libc.so.6 (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 libc.so
> and notices that it needs to be listed in .dynsym.

So it makes it look like there was an old reference to
__malloc_initialize_hook@GLIBC_2.0?

In that case I think we should not play games with the existing macro.

I would like to see a new macro that does what it says, rather than use the
existing macro in the wrong way. Even if the new macro is just a copy.

This looks like a real problem for glibc, particularly if we need to continue
to use, at least internally, certain old versions of symbols. So having a
new macro for this is fine.

-- 
Cheers,
Carlos.