Re: [Valgrind-developers] Switching PT_INTERP (helps Debian unstable)

[Josef W. <Jos...@gm...>]

On Saturday 08 October 2005 23:25, Stephen McCamant wrote:
> Current versions of Valgrind work less-than-perfectly with the latest
> version of glibc in Debian unstable (Debian version 2.3.5-6). Part of
> the problem seems to be that this build of libc6 manages to include
> even less symbol information for /lib/ld-linux.so.2 than the 2.3.2
> build from sarge did (or it's in a format that Valgrind can't
> handle). One of the relevant symbols is _dl_relocate_object,
> ...

AFAIK, this only happens if the runtime linker (/lib/ld-2.3.5.so) is stripped.
Valgrind reads both the normal symbol table and the dynamic symbol table. The
symbols disappeared from the dynamic table; and stripping gets rid of the 
normal symbol table.

Actually, I do not understand why on earth a distribution ships a stripped 
runtime linker. Note that this has nothing to do with debug information (!).

I fiddled around with this before the callgrind release, as I need to detect
"_dl_runtime_resolve". After a bug report for a callgrind alpha, I suspected
Suse 10.0 to be shipped with such a stripped runtime linker, but obviously 
they decided against.

>  Conditional jump or move depends on uninitialised value(s)
>     at 0x1B8ECB13: (within /lib/ld-2.3.5.so)
>     by 0x1B8E631C: (within /lib/ld-2.3.5.so)
>     by 0x1B8F2BDD: (within /lib/ld-2.3.5.so)
>     by 0x1B8E7675: (within /lib/ld-2.3.5.so)
>     by 0x1B8E47C6: (within /lib/ld-2.3.5.so)

There is a nice tool, the fenris debugger, see 
http://www.bindview.com/Services/RAZOR/Utilities/Unix_Linux/fenris_index.cfm
which includes a tool to regenerate the symbol table of a stripped lib or
binary (by using fingerprints of function codes).
Perhaps this way, you are able to "revive" the runtime linker?


> where I got the first stack trace above). Unfortunately, I don't
> believe there's any standard way (equivalent to LD_LIBRARY_PATH) to
> tell programs to use a different dynamic linker: "/lib/ld-linux.so.2"
> is hardcoded in binaries.

There is: try "/lib/ld-linux.so.2 /bin/ls"
You can start the runtime linker directly with the executables name as 
argument. This will run the executable with the specified runtime linker.

> Since Valgrind loads ld-linux.so.2 for its guests, it would be helpful
> if there was a way it could be told to switch in a different version.

But only if there is one...

Josef