|
From: adnan i. <adn...@se...> - 2010-10-04 15:51:54
|
Tom & John thanx again
This helped a lot to understand things. Running ldd on a simple dynamically
linked program shows following (which also clarifies from where these paths
are appearing in valgrind).
libc.so.6 => /lib32/tls/libc.so.6 (0x2aad7000)
/lib32/ld.so.1 (0x2aaa8000)
Version information:
./abi-n32-dyn:
libc.so.6 (GLIBC_2.0) => /lib32/tls/libc.so.6
/lib32/tls/libc.so.6:
ld.so.1 (GLIBC_PRIVATE) => /lib32/ld.so.1
ld.so.1 (GLIBC_2.3) => /lib32/ld.so.1
Adnan
On Mon, Oct 4, 2010 at 8:28 PM, John Reiser <jr...@bi...> wrote:
> > We have confirmed that right interpreter (linker mentioned in .interp
> > section of dynamically linked executable) is used. However when shared
> > objects are to be loaded, paths do not seem correct. For example: one of
> > the path is /lib32/tls/libc.so.6 which does not exist.
>
> It is normal for the PT_INTERP ld-linux to try several locations before
> finding any given shared library. For instance, if shell environment
> variable LD_LIBRARY_PATH is set, then those directories will be tried
> in order. After that, then ld-linux has a builtin search path of
> "/lib:/usr/lib".
>
> Mixed in with these are further choices which depend on detected hardware
> capabilities (perhaps floating point instruction set, etc.) and the
> environment that was assumed when glibc was built: kind of threads,
> preference for virtual addresses used by (and/or addressing mode used
> to access) Thread Local Storage (TLS), etc.
>
> However, if /lib32/tls/libc.so.6 is not found then ld-linux should
> proceed to try the next location for libc.so.6.
>
> _Perhaps_ there is a bug in valgrind such that the code that ld-linux
> uses to detect the actual hardware gets the wrong answer.
> _Perhaps_ it is possible that valgrind's placement of various things
> in the address space has confused ld-linux about TLS.
>
> In order to debug this, run
> LD_DEBUG=libs ./my_app <args>...
> LD_DEBUG=libs valgrind ./my_app <args>...
> and compare. In general, "LD_DEBUG=help /bin/date" gives documentation.
>
> A more detailed analysis can be obtained by comparing:
> strace -e files -o strace.plain ./my_app <args>...
> strace -e files -o strace.valgrind valgrind ./my_app <args>...
> which reveals *all* file accesses.
>
> --
>
>
> ------------------------------------------------------------------------------
> Virtualization is moving to the mainstream and overtaking non-virtualized
> environment for deploying applications. Does it make network security
> easier or more difficult to achieve? Read this whitepaper to separate the
> two and get a better understanding.
> http://p.sf.net/sfu/hp-phase2-d2d
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|