Re: _dl_profile_fixup & libc_p

["Ryan S. Arnold" <rsa at us dot ibm dot com>]

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???

Gian,

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
like:

  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.

-dynamic-linker /lib/ld.so.1

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