When I try to compile valgrind-3.9.0 on MIPS64 o32 it fails with the following error: {standard input}: Assembler messages: {standard input}:29: Error: relocation %highest isn't supported by the current ABI {standard input}:30: Error: relocation %higher isn't supported by the current ABI make[4]: *** [libcoregrind_mips64_linux_a-m_main.o] Error 1 MIPS32, MIPS64 n32 and MIPS64 n64 are ok.
For what are you trying to compile Valgrind? Currently Valgrind for mips is supporting only mips32/o32 ABI and mips64/n64 ABI. If you are trying to compile V for mips32/o32 you can try to configure V with extra CFLAGS and CXXFLAGS: CFLAGS="-mips32 -mabi=32" CXXFLAGS="-mips32 -mabi=32" or for mips64/n64 CFLAGS="-mips64 -mabi=64" CXXFLAGS="-mips64 -mabi=64" If you are using 32bit system on 64bit hardware and you want to configure V for mips64/n64 you should add: CFLAGS="-mabi=64" CXXFLAGS="-mabi=64" just to be sure that you are using right ABI and not n32.
(In reply to comment #1) > For what are you trying to compile Valgrind? I want to test it before adding support for it in BuildRoot distribution for MIPS architecture. > Currently Valgrind for mips is supporting only > mips32/o32 ABI and mips64/n64 ABI. If you are trying to compile V for > mips32/o32 you can try to configure V with extra CFLAGS and CXXFLAGS: > > CFLAGS="-mips32 -mabi=32" CXXFLAGS="-mips32 -mabi=32" > or for mips64/n64 > CFLAGS="-mips64 -mabi=64" CXXFLAGS="-mips64 -mabi=64" > > If you are using 32bit system on 64bit hardware and you want to configure V > for mips64/n64 you should add: > CFLAGS="-mabi=64" CXXFLAGS="-mabi=64" > just to be sure that you are using right ABI and not n32. I have tried to do the following compilations (all of them with the right FLAGS and ABI): mips32 : OK mips32r2 : OK mips32el : OK mips32el : OK mips64 o32 : FAIL mips64r2 o32 : FAIL mips64el o32 : FAIL mips64r2el o32 : FAIL mips64 n32 : OK mips64r2 n32 : OK mips64el n32 : OK mips64r2el n32 : OK mips64 n64 : OK mips64r2 n64 : OK mips64el n64 : OK mips64r2el n64 : OK
(In reply to comment #2) > (In reply to comment #1) > mips64 o32 : FAIL > mips64r2 o32 : FAIL > mips64el o32 : FAIL > mips64r2el o32 : FAIL Can you share how you configure Valgrind in these cases?
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > mips64 o32 : FAIL > > mips64r2 o32 : FAIL > > mips64el o32 : FAIL > > mips64r2el o32 : FAIL > > Can you share how you configure Valgrind in these cases? Here you have the first case, MIPS64 BigEndian o32 ABI. If you also want the other ones, I can share them too, but I think only one should be enough because the failure is always the same. This is how valgrind is configured (extracted from config.log): $ ./configure --target=mips64-buildroot-linux-gnu --host=mips64-buildroot-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix= --disable-gtk-doc --disable-doc --disable-do cs --disable-documentation --with-xmlto=no --with-fop=no --enable-ipv6 --enable-static --enable-shared --disable-tls And this is the information of the mips64-buiildroot-linux-gnu toolchain: $ ./output/host/usr/mips64-buildroot-linux-gnu/bin/gcc -v Using built-in specs. COLLECT_GCC=./output/host/usr/mips64-buildroot-linux-gnu/bin/gcc Target: mips64-buildroot-linux-gnu Configured with: ./configure --prefix=/home/test/buildroot/output/host/usr --sysconfdir=/home/test/buildroot/output/host/etc --enable-shared --enable-static --target=mips64-buildroot-linux-gnu --with-sysroot=/home/test/buildroot/output/host/usr/mips64-buildroot-linux-gnu/sysroot --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --with-gmp=/home/test/buildroot/output/host/usr --with-mpfr=/home/test/buildroot/output/host/usr --enable-target-optspace --disable-libquadmath --enable-tls --disable-libmudflap --enable-threads --with-mpc=/home/test/buildroot/output/host/usr --with-float=soft --disable-decimal-float --with-arch=mips64 --with-abi=32 --with-pkgversion='Buildroot 2014.02-rc3-00015-g70831d0-dirty' --with-bugurl=http://bugs.buildroot.net/ --enable-languages=c,c++ --with-build-time-tools=/home/test/buildroot/output/host/usr/mips64-buildroot-linux-gnu/bin --disable-libgomp Thread model: posix gcc version 4.7.3 (Buildroot 2014.02-rc3-00015-g70831d0-dirty) As you can see in that output, the toolchain generates code for MIPS64 BigEndian o32 ABI: --with-arch=mips64 : MIPS64 BigEndian --with-abi=32 : o32 ABI
What is the meaning of -march=mips64 with -mabi=32? What are you trying to achieve here?
(In reply to comment #5) > What is the meaning of -march=mips64 with -mabi=32? MIPS has three main ABIs: o32 (32-bit integer and pointer) N32 (64-bit integer, 32-bit pointer) N64 (64-bit integer and pointer) You can use a MIPS 32-bit processor with the o32 ABI. You can use a MIPS 64-bit processor with the o32, n32 and n64 ABIs. > What are you trying to achieve here? Nothing, but the combination of MIPS64 with o32 ABI is possible, so that's why I have opened this bug.
(In reply to comment #6) > (In reply to comment #5) > > What is the meaning of -march=mips64 with -mabi=32? > > MIPS has three main ABIs: > o32 (32-bit integer and pointer) > N32 (64-bit integer, 32-bit pointer) > N64 (64-bit integer and pointer) > > You can use a MIPS 32-bit processor with the o32 ABI. > You can use a MIPS 64-bit processor with the o32, n32 and n64 ABIs. > > > What are you trying to achieve here? > > Nothing, but the combination of MIPS64 with o32 ABI is possible, so that's > why I have opened this bug. Compiling code for mips64 with o32 ABI is not a regular case, at least not that I am aware of. Bear in mind that there is a difference between 1. mips64 code and 2. mips32 o32 code being executed on mips64 board.
(In reply to comment #7) > Compiling code for mips64 with o32 ABI is not a regular case, at least > not that I am aware of. Yes, is not a regular case, but it is a case :) > Bear in mind that there is a difference between 1. mips64 code and > 2. mips32 o32 code being executed on mips64 board. Yes, but..., what's your point with that? I think is not related with the problem we are talking here.
(In reply to comment #8) > (In reply to comment #7) > > Compiling code for mips64 with o32 ABI is not a regular case, at least > > not that I am aware of. > > Yes, is not a regular case, but it is a case :) > It's an irregular case nobody should try. > > Bear in mind that there is a difference between 1. mips64 code and > > 2. mips32 o32 code being executed on mips64 board. > > Yes, but..., what's your point with that? I think is not related with the > problem we are talking here. My point is that - from what I understand from this bug report so far - is that you are trying to compile mips64 o32 version of Valgring, which is an irregular meaningless case that no one would benefit from. Thus, it would be wrong to fix it.
(In reply to comment #9) > My point is that - from what I understand from this bug report so far - > is that you are trying to compile mips64 o32 version of Valgring, which > is an irregular meaningless case that no one would benefit from. > Thus, it would be wrong to fix it. So there won't be support for MIPS64 o32 in Valgrind, right?
(In reply to comment #10) > (In reply to comment #9) > > My point is that - from what I understand from this bug report so far - > > is that you are trying to compile mips64 o32 version of Valgring, which > > is an irregular meaningless case that no one would benefit from. > > Thus, it would be wrong to fix it. > > So there won't be support for MIPS64 o32 in Valgrind, right? > So there won't be support for MIPS64 o32 in Valgrind, right? I am not aware there is any program in use anywhere that is MIPS64 + o32. So, no, we do not plan to do it for Valgrind.
(In reply to comment #11) > I am not aware there is any program in use anywhere that is MIPS64 + o32. > So, no, we do not plan to do it for Valgrind. Ok, maybe it doesn't have sense to make Valgrind compile on MIPS64 o32. But..., will Valgrind be able to handle o32 applications running on MIPS64?
(In reply to comment #12) > (In reply to comment #11) > > I am not aware there is any program in use anywhere that is MIPS64 + o32. > > So, no, we do not plan to do it for Valgrind. > > Ok, maybe it doesn't have sense to make Valgrind compile on MIPS64 o32. > But..., will Valgrind be able to handle o32 applications running on MIPS64? Yes, this is already the case.
(In reply to comment #13) > Yes, this is already the case. Then I guess this bug can be closed :-)