This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PLT entry not initialized when loading a library, but called nevertheless
- From: Igor Pashev <pashev dot igor at gmail dot com>
- To: binutils at sourceware dot org
- Cc: sergey dot prokhorenko at gmail dot com
- Date: Tue, 11 Dec 2012 19:41:20 +0400
- Subject: Re: PLT entry not initialized when loading a library, but called nevertheless
- References: <50C7400B.5090906@gmail.com>
11.12.2012 18:15, Sergey Prokhorenko ÐÐÑÐÑ:
> Hello.
>
> Sorry to bother if that's not an appropriate mailing list but I'm not
> really sure where to postthis question about ld and shared library loading.
>
> I found a strange bug when loading a nested shared library. Say I have
> libA that depends on libB that depends on libC. A/B I compile myself and
> C is precompiled in binary form by 3rd party (not that it's really
> important but).
>
> When I start the appit crashes with SIGSEGV
> after__static_initialization_and_destruction_0in libC, while calling
> MyFunc@plt from my "common to all" library libX. The stack is as follows:
>
> 0x12345
> __static_initialization_and_destruction_0
> ...
> dlopen("libA")
>
> I ran app with LD_DEBUG=bindings and found out that libC can't find a
> symbol:
> 10272: /media/EXT/work//libC.so: error: symbol lookup error:
> undefined symbol: omp_set_num_threads (fatal)
>
> which is probably the 3rd-party libC problemBUT after that, it continues
> to resolve symbols inside libA while completely skipping the rest of
> libC and all of the libB ones. So that when it comes to calling static
> initof libC then half of PLT entries are unresolved, thus the crash. Or
> that's how I see it.
>
> I have built anoptimized version of my app and there for some reason it
> is able to resolve that symbol (to libgomp). Also I see there that
> without unresolved omp_ error it completes libC bindings then continues
> with libB bindings and then with libA bindings. This is to compare to
> the non-optimized version (as described above) where it does not
> complete libC bindings and does not do libB.
>
> So my question is(if you allow as I'm not really big expert in this are)
> - can it be that this is dlopen/ld bugand am I in the correct mail list
> after all?
>
> The environment is Ubuntu 12.04 x86_64 with latest updates, app is i386
> though, compiled with stock gcc 4.6. Iam not sure where and how libC was
> compiled.Since everything worked fine when compilingon Ubuntu 11.10 I
> may suspect that libC was also compiled here, and the bug appeared when
> we upgraded to Ubuntu 12.04 and its gcc/ld.The bug was gone when I get
> updated libC version built on 12.04 from3rd party. Still I wonder why
> itis possible to leave shared library (even built by some other tool) in
> a half-initialized state andare my conclusions above correct.
>
> Thanks, Sergey.
This is hardly a binutils bug, especially on linux/x86_64 :-)
I can guess, that libC is not linked to libgomp (from GCC) or whichever
OpenMP library being used.