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: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Celelibi <celelibi at gmail dot com>
- Cc: Ondřej Bílka <neleai at seznam dot cz>, libc-help at sourceware dot org
- Date: Mon, 29 Apr 2013 16:35:23 -0700
- 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> <CAJR2zJ85ehHFMzuYw1mNqjhdypAMhcDSxxag_BC=ew7BL5-OBg at mail dot gmail dot com> <CAJR2zJ8K=AQu4ikr2WXzxyFCh=KLwqBPJg5vASbuLx8wLoMVXA at mail dot gmail dot com> <CAJR2zJ9rOGpA0PNo_dPw_EeBmpM-Y3RLE0HTB8NC5sBkQa6_og at mail dot gmail dot com>
On Mon, Apr 29, 2013 at 1:09 PM, Celelibi <celelibi@gmail.com> wrote:
> 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.
I believe this is working as intended.
> 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
Your final link command is incorrect. Using "gcc -o dyn dyn.c -ldl" instead.
LD_DEBUG=bindings ./dyn |& grep __cyg_profile_func
11096: binding file ./foo.so [0] to
/lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol
`__cyg_profile_func_enter'
11096: binding file ./foo.so [0] to
/lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol
`__cyg_profile_func_exit'
That is, libc.so.6 provides empty __cyg_profile_* stubs, and you *must*
override them by linking your own __cyg_profile_* into the main executable,
or a library that appears on the link line before libc.so.6 does.
If you don't (as is the case here), then you lose to libc.so.6 ones.
Cheers,
--
Paul Pluzhnikov