This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: What does ld.so do that dlopen don't do when loading shared libraries
- From: Celelibi <celelibi at gmail dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: libc-help at sourceware dot org
- Date: Mon, 29 Apr 2013 00:58:28 +0200
- Subject: Re: What does ld.so do that dlopen don't do when loading shared libraries
- References: <CAJR2zJ-DZ+G-FZw_2SSTPjF-BVkEkmfO9EcSfbUjTa_xKbMcfg at mail dot gmail dot com> <20130428213419 dot GA30730 at domone dot kolej dot mff dot cuni dot cz>
2013/4/28, OndÅej BÃlka <neleai@seznam.cz>:
> 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
statically linked.
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".