|
From: Maran P. <mpa...@ca...> - 2015-04-16 07:17:30
|
Please check if the revision r3108 is included in the version you use. If not, including the patch might fix the issue. The patch is part of fixing the below bugz. https://bugs.kde.org/show_bug.cgi?id=341997 On 04/15/2015 11:42 PM, Zhu, Yanwen wrote: > > Leonard, > > I finally got valgrind compiled correctly. And I just run valgrind > without attaching to any command in MIPS64 OCTEON target, I got the > following error. Looks like some of the shared libraries are missing: > > # uname -a > > Linux ViaSat 3.10.20-rt14-Cavium-Octeon #1 SMP Wed Apr 15 09:30:37 EDT > 2015 mips64 GNU/Linux > > # which valgrind > > /usr/bin/valgrind > > # valgrind > > valgrind: failed to start tool 'memcheck' for platform 'mips64-linux': > No such file or directory > > # strace valgrind > > execve("/usr/bin/valgrind", ["valgrind"], [/* 20 vars */]) = 0 > > brk(0) = 0x100cb0f4 > > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, > 0) = 0x77dad000 > > uname({sys="Linux", node="ViaSat", ...}) = 0 > > access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or > directory) > > open("/lib32-fp/tls/octeon3/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 > ENOENT (No such file or directory) > > stat("/lib32-fp/tls/octeon3", 0x7fad6050) = -1 ENOENT (No such file or > directory) > > open("/lib32-fp/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No > such file or directory) > > stat("/lib32-fp/tls", 0x7fad6050) = -1 ENOENT (No such file or > directory) > > open("/lib32-fp/octeon3/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT > (No such file or directory) > > stat("/lib32-fp/octeon3", 0x7fad6050) = -1 ENOENT (No such file or > directory) > > Attached is my own makefile to build valgrind, maybe something is not > right in that make file? > > Thanks, > > Yanwen > > *From:*Crestez Dan Leonard [mailto:cdl...@gm...] > *Sent:* Tuesday, April 14, 2015 6:02 PM > *To:* Zhu, Yanwen; Valgrind Developers > *Subject:* Re: Valgrind 13854: Cross compiling for Cavium MIPS64, N32 ABI > > Hello, > > You seem to be building for mips32, this is wrong. Instead of _mips32_ > those object files should all contain "_mips64n32_". > > You need to make sure your configure target is some form of mips64*, > not mips32. What this patch does is add support for the N32 ABI as a > secondary arch of mips64. What used to only build valgrind for mips64 > will now build a second set of binaries for the N32 ABI. The main > valgrind launcher will pick the correct mips64/mips64n32 version of > the tool based on flags in the elf header. > > You also need to avoid including -mabi inside any explicit CFLAGS. > Apparently gcc gets confused by multiple -mabi=* flags instead of just > using the last option. > > Maybe you show how you are running the configure script? Also make > sure you reran autogen.sh after patching and cleaned any stale binaries. > > I included the valgrind-developers list because this mail thread > should be public in case anyone has similar issues. > > Regards, > > Leonard > > On Wed, Apr 15, 2015 at 12:31 AM, Zhu, Yanwen <Yan...@vi... > <mailto:Yan...@vi...>> wrote: > > Leonard, > > Thanks for your reply, I just fixed some errors during the patch. > You’re right, not too bad, just 3 files that I had to manually port > the changes. > > I am building valgrind for MIPS64 with -mabi=n32 using the OCTEOM > cross compiler and I am seeing the following error in the linking phase: > > ../coregrind/link_tool_exe_linux 0x38000000 > /home/yzhu/workspace/buildroot/buildroot/output/kg255x.v2_pp_devel/tools/ext/bin/mips64-octeon-linux-gnu-gcc > --sysroot=/home/yzhu/workspace/buildroot/buildroot/output/kg255x.v2_pp_devel/tools > -Os -pipe -Os -mtune=mips64 -mabi=n32 -D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-melf32btsmipn32 > -march=octeon3 > -I/home/yzhu/workspace/buildroot/buildroot/output/kg255x.v2_pp_devel/toolchain/linux/include > -Wno-long-long -Os -pipe -Os -mtune=mips64 -mabi=n32 > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 > -Wl,-melf32btsmipn32 -march=octeon3 -fno-stack-protector -mabi=n32 > -Wl,-melf32btsmipn32 -march=octeon3 > -L/home/yzhu/workspace/buildroot/buildroot/output/kg255x.v2_pp_devel/tools/lib > -L/home/yzhu/workspace/buildroot/buildroot/output/kg255x.v2_pp_devel/tools/usr/lib > -o memcheck-mips32-linux -O2 -g -Wall -Wmissing-prototypes -Wshadow > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations > -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -O2 -static > -nodefaultlibs -nostartfiles -u __start > memcheck_mips32_linux-mc_leakcheck.o > memcheck_mips32_linux-mc_malloc_wrappers.o > memcheck_mips32_linux-mc_main.o memcheck_mips32_linux-mc_translate.o > memcheck_mips32_linux-mc_machine.o memcheck_mips32_linux-mc_errors.o > ../coregrind/libcoregrind-mips32-linux.a ../VEX/libvex-mips32-linux.a > -lgcc > > ../coregrind/libcoregrind-mips32-linux.a(libcoregrind_mips32_linux_a-m_main.o): > In function `__start': > > m_main.c:(.text+0xc): undefined reference to `_gp_disp' > > m_main.c:(.text+0x10): undefined reference to `_gp_disp' > > collect2: error: ld returned 1 exit status > > make[4]: *** [memcheck-mips32-linux] Error 1 > > I don’t know what’s going on here, any suggestions? > > Thanks, > > Yanwen > > *From:*Crestez Dan Leonard [mailto:cdl...@gm... > <mailto:cdl...@gm...>] > *Sent:* Tuesday, April 14, 2015 3:08 PM > *To:* Zhu, Yanwen > *Subject:* Re: Valgrind 13854: Cross compiling for Cavium MIPS64, N32 ABI > > Hello, > > The patches are against SVN trunk at around the time the patches were > posted (it differs between V1 and V2). Backporting them to 3.10.1 > should not be terribly difficult. They won't apply cleanly but I > expect the issues to be minor and easily solvable. Since the tilegx > port was integrated a few days ago I expect they won't apply cleanly > on svn trunk either, at least not until I rebase and post the next > version. > > You can also try to compile directly from the git repos mentioned in > the tracker item. That should "just work". > > If you have problems compiling you should mention the actual build > errors as well as compiler/target details. Support for N32 should be > generic but I'm only actually targeting octeon chips using the cavium > gcc-4.7 toolchain. > > Regards, > > Leonard > > On Tue, Apr 14, 2015 at 7:16 PM, <Yan...@vi... > <mailto:Yan...@vi...>> wrote: > > Hi Leonard, > > I'm trying to apply your patches for mips64n32 on valgrind 3.10.1 and > there some some errors, I manually fixed the patching errors, however, > I have some problem compiling it. Looks to me that your patches were > not made based on 3.10.1. What version of valgrind were your patches > made from? Do you have patches for 3.10.1? > > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers -- Maran Pakkirisamy |