|
From: John R. <jr...@bi...> - 2010-10-04 15:28:47
|
> 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. -- |