This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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]

Solving symbols from different shared objects?


Hi Cary, we are testing trunk binutils and found lots of failures, one
scenario (unresolved reference to "dlsym") is linking an executable
that involves 3 shared libraries, A.so, B.so and libdl.so.

In A.so, there is an undefined, un-versioned "dlsym"
In B.so, there is an undefined, versioned "dlsym@@GLIBC_2.2.5"
In libdl.so, there is the definition for "dlsym@@GLIBC_2.2.5".

The old binutils (forked at the end of 2014), which we are now using,
solves dlsym in A.so using definition in libdl.so in
Symbol_table::define_default_version.

However, in fixing the bug -
https://sourceware.org/bugzilla/show_bug.cgi?id=16979
Symbol_table::define_default_version is modified, so that definition
in libdl.so no longer applies to A.so, the rationale being (quote from
comment) "if two symbols are from different objects, they are
different symbols."

To fix the problem, I modified it so that "if two symbols are from
different objects, *and both of them are defined*, they are different
symbols.", as the patch illustrates below -

diff --git a/gold/symtab.cc b/gold/symtab.cc
index b31794a..cdeef7f 100644
--- a/gold/symtab.cc
+++ b/gold/symtab.cc
@@ -881,7 +881,7 @@
Symbol_table::define_default_version(Sized_symbol<size>* sym,
               && sym->is_from_dynobj())
        ;
       else if (pdef->second->is_from_dynobj()
-              && sym->is_from_dynobj()
+              && sym->is_from_dynobj() && pdef->second->is_defined()
               && pdef->second->object() != sym->object())
         ;
       else

Do you think this is a a reasonable fix?

Thanks,
Han


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