|
From: Crestez D. L. <cdl...@gm...> - 2015-04-14 22:02:51
|
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...> 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...] > *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...> 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? > |
|
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 |
|
From: Zhu, Y. <Yan...@vi...> - 2015-04-16 16:47:56
|
It turned out that after applying patches from Bug 339288, the problem went away. Now I'm seeing a new issue when running Valgrind 3.10.1 on MIPS64 Cavium OCTEON: # valgrind uia_init ==1932== Memcheck, a memory error detector ==1932== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==1932== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==1932== Command: uia_init ==1932== ==1932== Invalid write of size 4 ==1932== at 0x4001628: _dl_start_user (in /lib/ld-2.16.so.new) ==1932== by 0x40015B8: __start (in /lib/ld-2.16.so.new) ==1932== Address 0x7e6afc78 is on thread 1's stack ==1932== 8 bytes below stack pointer ==1932== And Valgrind is hung from there. Anyone has any ideas? Thanks, Yanwen From: Maran Pakkirisamy [mailto:mpa...@ca...] Sent: Thursday, April 16, 2015 3:17 AM To: Zhu, Yanwen; Crestez Dan Leonard; Valgrind Developers Subject: Re: [Valgrind-developers] Valgrind 13854: Cross compiling for Cavium MIPS64, N32 ABI 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...<mailto:Val...@li...> https://lists.sourceforge.net/lists/listinfo/valgrind-developers -- Maran Pakkirisamy |
|
From: Zhu, Y. <Yan...@vi...> - 2015-04-15 18:12:50
Attachments:
valgrind.mk
|
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?
|