Bug 16979

Summary: gold fails to override built-in symbols
Product: binutils Reporter: Adar Lieber-Dembo <adembo>
Component: goldAssignee: Ian Lance Taylor <ian>
Status: RESOLVED FIXED    
Severity: normal CC: ccoutant, mike.percy
Priority: P2    
Version: 2.24   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: test case for symbol overriding

Description Adar Lieber-Dembo 2014-05-23 00:34:37 UTC
Created attachment 7612 [details]
test case for symbol overriding

I've been trying to dynamically link tcmalloc into my application and was troubled to see that sometimes the link didn't "take" (i.e. ldd revealed no dependency on libtcmalloc.so and the built-in libc malloc was invoked by the application). After debugging for a little while, I've produced a simple test case showing the problem. When /usr/bin/ld is symlinked to ld.bfd, the test passes. When it's symlinked to ld.gold, the test fails. This is how my binutils package layout works (I'm running Ubuntu 14.04).

I'm not familiar enough with the details of linking to understand why it's failing, but as gold is supposed to be a drop-in replacement for ld, I figured this is a reasonable place to start.
Comment 1 Sourceware Commits 2016-03-31 02:17:03 UTC
The master branch has been updated by Cary Coutant <ccoutant@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b60ecbc6ddeaf7af8f2515841b58035f0d4d2db7

commit b60ecbc6ddeaf7af8f2515841b58035f0d4d2db7
Author: Cary Coutant <ccoutant@gmail.com>
Date:   Wed Mar 30 19:14:16 2016 -0700

    Don't override definition a shared object by one in a later shared object.
    
    In PR 16979, a reference to malloc is being resolved to an unversioned
    reference in libmalloc.so. When linked with --as-needed, however, the
    dynamic table does not list libmalloc.so as a DT_NEEDED library.
    
    If we have a reference to an unversioned symbol in a shared object,
    and we later see a versioned definition in another shared object, we
    were overriding the first definition with the second in the process of
    defining the default version. As a result, we no longer think that the
    first shared object was actually needed to resolve any symbols, and we
    don't list it as a DT_NEEDED library.
    
    This patch fixes the problem by treating the two definitions as separate
    symbols, so the second definition does not override the first.
    
    2016-03-30  Cary Coutant  <ccoutant@gmail.com>
    
    gold/
    	PR gold/16979
    	* symtab.cc (Symbol_table::define_default_version): Check for case
    	where symbols are both in different shared objects.
Comment 2 Cary Coutant 2016-03-31 02:18:12 UTC
Fixed.