This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]