This is the mail archive of the
mailing list for the glibc project.
Re: _dl_profile_fixup & libc_p
On Wed, 2008-03-19 at 16:48 +0100, Gian Lorenzo Meocci wrote:
> I think that this is not a bug of glibc. Otherwise I am using
> glibc-2.7 under kernel 2.6.22-3-686.
> The problem for me is in _dl_fixup, that is instrumented:
> 08095e70 <_dl_fixup>:
> 8095e70: 55 push %ebp
> 8095e71: 89 e5 mov %esp,%ebp
> 8095e73: 57 push %edi
> 8095e74: 56 push %esi
> 8095e75: 53 push %ebx
> 8095e76: 83 ec 30 sub $0x30,%esp
> 8095e79: e8 b2 c8 fb ff call 8052730 <_mcount>
> I believe that in this case the proper function must be
> _dl_profile_fixup. Is there any manual about develop of glibc???
I've not dealt with the profiled versions of glibc before.
_dl_fixup is in the loader.
Is there a profiled version of the loader that gets built?
When you link against -lc_p I'm not sure if it changes which loader is
referenced. Run this against your application:
readelf -l <application> | grep INTERP -A 3
It'll tell you which loader you're using. You should see something
INTERP 0x000154 0x10000154 0x10000154 0x0000d 0x0000d R 0x1
[Requesting program interpreter: /lib/ld.so.1]
When you compile your program with -v you can see in what order GCC
links the libraries and which ones it links. It'll tell you which
loader it is using when it invokes collect2, e.g.
Regarding the segmentation fault:
const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);
A crash in this code is often due to a disparity between the loader and
the libc. One populates the link_map and the other references it. If
they were built with different assumptions about the data-type sizes or
array sizes you can end up referencing an incorrect struct element.
Ryan S. Arnold