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