What does ld.so do that dlopen don't do when loading shared libraries
Sun Apr 28 22:58:00 GMT 2013
2013/4/28, Ondřej Bílka <firstname.lastname@example.org>:
> Did you tried to ask at tau mailing list/forum? Here I could give only
> generic advice.
I did, yes. (Still waiting for an anwser.)
But since it seems to me like a ld.so vs. dlopen issue, I
> Library constructors and destructors are run by dlopen so problem is
> probably somewhere else.
Must be soemthing else then. :(
>> I join foo.c sep.c and dyn.c as an example.
>> I can also provide the generated binaries if requested.
> Did you tried to look if there is something interesting in objdump foo.so?
Yes, I already tortured it a bit. :)
It contains a lot of things... It grew from 6.5Ko to 436Ko. It depends
on a several standard libraries, thought it seems like TAU itself is
It defines a lot of symbols (1143), and have only 177 undefined symbols.
It adds calls to __cyg_profile_func_enter@plt and
__cyg_profile_func_exit@plt at the begining and end of my function(s).
I guess that's how it profiles it.
The code of the entrypoint is not the same with and without TAU
although it seems to do something similar but I cannot gurantee (my
x86_64 is not very fluent).
And... Well, that's pretty much all I can tell. Nothing that could say
"hey, look here, I can't work without this".
More information about the Libc-help