This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] malloc: Use compat_symbol_reference in libmcheck [BZ #22050]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 31 Aug 2017 17:28:27 +0200
- Subject: Re: [PATCH] malloc: Use compat_symbol_reference in libmcheck [BZ #22050]
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 828374ACC7
- References: <20170831095213.42A4F43994318@oldenburg.str.redhat.com> <email@example.com>
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.