|
From: adnan i. <adn...@se...> - 2010-10-04 13:30:18
|
Hi, Valgrinding of any dynamically linked program starts with the valgrinding of linker. this also results in loading (via sys_open/sys_read OR mmapping) several shared objects (e.g., ld.so.cache and libc-2.9.so). I am trying to figure out from where the path of these shared objects is obtained/controlled. For example in x86-linux the path used for libc-2.9.sois /lib/tls/i686/cmov/ libc-2.9.so. I need to do so because it appears that for other ports of valgrind it shall be necessary to replace these paths with more appropriate ones. Thanx Adnan |
|
From: Tom H. <to...@co...> - 2010-10-04 13:37:13
|
On 04/10/10 14:02, adnan iqbal wrote: > Valgrinding of any dynamically linked program starts with the > valgrinding of linker. this also results in loading (via > sys_open/sys_read OR mmapping) several shared objects (e.g., > ld.so.cache and libc-2.9.so <http://libc-2.9.so>). > I am trying to figure out from where the path of these shared objects is > obtained/controlled. For example in x86-linux the path used for > libc-2.9.so <http://libc-2.9.so> is /lib/tls/i686/cmov/libc-2.9.so > <http://libc-2.9.so>. I need to do so because it appears that for other > ports of valgrind it shall be necessary to replace these paths with more > appropriate ones. This is nothing to do with valgrind - valgrind just runs ld.so in the same way the kernel normally does and ld.so decides what other shared libraries are needed and where to load then from. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: adnan i. <adn...@se...> - 2010-10-04 14:06:41
|
Hi Tom, Thanx for a very quick reply. Your answer is certainly very logical and sensible. However the problem that we are having right now, confuses things a bit. Here goes the complete scenario. We have ported valgrind for mips to an extent that we think almost all available instructions and complete coregrind has been ported for NABI32. Statically compiled C/Assembaly programs run perfectly fine whereas dynamically linked programs cause some trouble. 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. Regards Adnan On Mon, Oct 4, 2010 at 6:36 PM, Tom Hughes <to...@co...> wrote: > On 04/10/10 14:02, adnan iqbal wrote: > > Valgrinding of any dynamically linked program starts with the >> valgrinding of linker. this also results in loading (via >> sys_open/sys_read OR mmapping) several shared objects (e.g., >> ld.so.cache and libc-2.9.so <http://libc-2.9.so>). >> >> I am trying to figure out from where the path of these shared objects is >> obtained/controlled. For example in x86-linux the path used for >> libc-2.9.so <http://libc-2.9.so> is /lib/tls/i686/cmov/libc-2.9.so >> <http://libc-2.9.so>. I need to do so because it appears that for other >> >> ports of valgrind it shall be necessary to replace these paths with more >> appropriate ones. >> > > This is nothing to do with valgrind - valgrind just runs ld.so in the same > way the kernel normally does and ld.so decides what other shared libraries > are needed and where to load then from. > > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ > |
|
From: Tom H. <to...@co...> - 2010-10-04 14:10:29
|
On 04/10/10 15:06, adnan iqbal 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. So what should it be? What does ldd say about the libraries that the program needs? Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
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. -- |
|
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
>
|