What does ld.so do that dlopen don't do when loading shared libraries

Celelibi celelibi@gmail.com
Mon Apr 29 20:09:00 GMT 2013

(triple reply combo :p)

After a bit of investigation, it looks like it's not only TAU or
profilers that suffer from this bug, but every tool relying on
instrumentation by gcc.

gcc's option -finstrument-functions add calls to
__cyg_profile_func_enter@plt and __cyg_profile_func_exit@plt at the
begining and end of every function. Thus, a tool just have to define
the real functions and then can do whatever it want.

And the thing is that, even thought the calls to these PLT entries are
actually executed, execution never reach the actual functions (when
opened with dlopen). I tried to debug instruction-by-instruction, but
got lost inside ld-linux-x86-64.so.2.
I think it just refuse to resolve the symbol or something like that.
I think you should be able to explain a bit what happens. :)

Here I join a small example (independant of TAU or anything) to show
this behavior

Compilation commands:
gcc -shared -fPIC -finstrument-functions -o foo.so foo.c
gcc -ldl -o dyn dyn.c

(dyn.c didn't change, but I still join it for self-containment of this message.)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.c
Type: text/x-csrc
Size: 363 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-help/attachments/20130429/f3834a0a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dyn.c
Type: text/x-csrc
Size: 258 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-help/attachments/20130429/f3834a0a/attachment-0001.bin>

More information about the Libc-help mailing list