[Bug ld/26018] --dynamic-list* doesn't work before -Bsymbolic and -Bsymbolic-functions

[matz at suse dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=26018

Michael Matz <matz at suse dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de

--- Comment #8 from Michael Matz <matz at suse dot de> ---
This might have broken usage in the wild.  In libqt4 this feature is used as
follows:

g++ ... -shared -Wl,-Bsymbolic-functions -Wl,--dynamic-list,QtCore.dynlist ...

with QtCore.dynlist only containing function names:

-----------------
{
     extern "C" {
         "qt_startup_hook";
         "qt_addObject";
         "qt_removeObject";
     };
     extern "C++" {
         "QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)";
     };
};
-----------------

The intent is that all functions are bound locally, except for the few ones
explicitely mentioned.  That worked fine with binutils 2.32, an excerpt from
the
relocations:

...
00000000004e4bc8  0000047e00000006 R_X86_64_GLOB_DAT      00000000004e5900
_ZN7QString11shared_nullE + 0
...

I've singled out this one because it's important: this shared_null member _must
not_ be bound symbolically, there must be only one in the process image, and
there exist (non-PIE) binaries that contain COPY relocations on it.  So
relocations to this symbol need to stay in the shared lib, i.e. it must remain
dynamic.

With binutils 2.35 _ZN7QString11shared_nullE is bound symbolically, there's
no trace of it in the relocation of libQtCore.so.4 anymore, breaking stuff
in interesting ways (e.g. some executables hang at start).

I think what this (old) libqt4 link command is doing is reasonable: it wants
default behaviour for symbol binding, then overrides this for functions (to be
bound symbolically) and then overrides _that_ for some further functions (to
again be bound as per default, i.e. late).  I.e. the overall expectation that
data objects remain bound late with that command line seem sensible.

I haven't yet verified if this commit is really at fault, but it looks at least
related and I wanted to leave a trace in case I can't continue with analysis 
tomorrow.  If it's not this, then it's some other change since 2.32.

-- 
You are receiving this mail because:
You are on the CC list for the bug.