|
From: Zhu, Y. <Yan...@vi...> - 2015-04-15 18:12:50
|
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?
|