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

[Ãngel GonzÃlez <keisial at gmail dot com>]

On 29/04/13 22:09, Celelibi wrote:
> (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.)
>
>
> Regards,
>
> Celelibi
Yes, it's strange. (I confirm the observed behavior)

Kind of a workaround, if you do:
LD_PRELOAD=$PWD/foo.so ./dyn

Then the profile_funcs are called. Which supports your assumption, as
foo.so is loaded by ld.so in that case.
I have no idea why it does so. Looks as if dlopen() missed doing something.