[Buildroot] [RFC] best way to fix a valgrind gcc 5 compile error on MIPS Octeon2

[Buildroot] [RFC] best way to fix a valgrind gcc 5 compile error on MIPS Octeon2

[Charles Hardin]

So compiling for a Cavium Octeon 2 processor with 2017.02.x yields the
following error.


/home/vagrant/onebloxv1_rootfs.build/host/usr/bin/mips64-linux-gcc
-DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub -I../VEX/pub
-DVGA_mips64=1 -DVGO_linux=1 -DVGP_mips64_linux=1
-DVGPV_mips64_linux_vanilla=1 -Ipriv -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -std=gnu99 -Wall
-Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes
-Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings
-Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
-Wmissing-parameter-type -Wold-style-declaration -fno-stack-protector
-fno-strict-aliasing -fno-builtin  -march=mips64 -Wbad-function-cast
-fstrict-aliasing -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -O2 -g2 -fno-stack-protector -march=octeon2 -c -o
priv/libvex_mips64_linux_a-main_globals.o `test -f 'priv/main_globals.c' ||
echo './'`priv/main_globals.c

*priv/main_globals.c:1:0:* *error: *'*-mips64*' conflicts with the other
architecture options, which specify a mips64r2 processor



* ^*

Makefile:1309: recipe for target
'priv/libvex_mips64_linux_a-main_globals.o' failed

make[6]: *** [priv/libvex_mips64_linux_a-main_globals.o] Error 1

make[6]: *** Waiting for unfinished jobs....



The quickest/dirtiest/probably wrong solution I tried was to switch to an
"mtune" instead of doubling on the march.

*diff --git a/package/valgrind/valgrind.mk <http://valgrind.mk>
b/package/valgrind/valgrind.mk <http://valgrind.mk>*

*index ccc6cc3..031e648 100644*

*--- a/package/valgrind/valgrind.mk <http://valgrind.mk>*

*+++ b/package/valgrind/valgrind.mk <http://valgrind.mk>*

@@ -34,7 +34,7 @@ VALGRIND_CFLAGS = \

 # and pass the right -march option, so they take precedence over

 # Valgrind's wrongfully detected value.

 ifeq ($(BR2_mips)$(BR2_mipsel)$(BR2_mips64)$(BR2_mips64el),y)

-VALGRIND_CFLAGS += -march=$(BR2_GCC_TARGET_ARCH)

+VALGRIND_CFLAGS += -mtune=$(BR2_GCC_TARGET_ARCH)

 endif



 VALGRIND_CONF_ENV = CFLAGS="$(VALGRIND_CFLAGS)"



And that gets past the compiler errors... so??? is that what people are
doing in this case?

Regards,
Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170717/7134c93c/attachment.html>

[Buildroot] [RFC] best way to fix a valgrind gcc 5 compile error on MIPS Octeon2

[Thomas Petazzoni]

Hello,

On Mon, 17 Jul 2017 20:00:56 -0700, Charles Hardin wrote:
> So compiling for a Cavium Octeon 2 processor with 2017.02.x yields the
> following error.
> 
> 
> /home/vagrant/onebloxv1_rootfs.build/host/usr/bin/mips64-linux-gcc
> -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub -I../VEX/pub
> -DVGA_mips64=1 -DVGO_linux=1 -DVGP_mips64_linux=1
> -DVGPV_mips64_linux_vanilla=1 -Ipriv -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -std=gnu99 -Wall
> -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes
> -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings
> -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
> -Wmissing-parameter-type -Wold-style-declaration -fno-stack-protector
> -fno-strict-aliasing -fno-builtin  -march=mips64 -Wbad-function-cast
> -fstrict-aliasing -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64  -O2 -g2 -fno-stack-protector -march=octeon2 -c -o
> priv/libvex_mips64_linux_a-main_globals.o `test -f 'priv/main_globals.c' ||
> echo './'`priv/main_globals.c
> 
> *priv/main_globals.c:1:0:* *error: *'*-mips64*' conflicts with the other
> architecture options, which specify a mips64r2 processor
> 
> * ^*
> 
> Makefile:1309: recipe for target
> 'priv/libvex_mips64_linux_a-main_globals.o' failed
> 
> make[6]: *** [priv/libvex_mips64_linux_a-main_globals.o] Error 1
> 
> make[6]: *** Waiting for unfinished jobs....

Can you give more details on how to reproduce this build failure? I.e
your Buildroot .config and toolchain (if you're using an external
toolchain) ?

> *--- a/package/valgrind/valgrind.mk <http://valgrind.mk>*
> 
> *+++ b/package/valgrind/valgrind.mk <http://valgrind.mk>*
> 
> @@ -34,7 +34,7 @@ VALGRIND_CFLAGS = \
> 
>  # and pass the right -march option, so they take precedence over
> 
>  # Valgrind's wrongfully detected value.
> 
>  ifeq ($(BR2_mips)$(BR2_mipsel)$(BR2_mips64)$(BR2_mips64el),y)
> 
> -VALGRIND_CFLAGS += -march=$(BR2_GCC_TARGET_ARCH)
> 
> +VALGRIND_CFLAGS += -mtune=$(BR2_GCC_TARGET_ARCH)

This looks wrong, because BR2_GCC_TARGET_ARCH is what is already passed
to gcc as -march through the toolchain wrapper, so I don't see why we
get this issue.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [RFC] best way to fix a valgrind gcc 5 compile error on MIPS Octeon2

[Thomas Petazzoni]

Hello,

Adding Vicente in Cc.

On Wed, 19 Jul 2017 00:04:39 +0000, Charles Hardin wrote:
> Looks like pilot error - we were using a gcc compiled toolchain and even though
> this sets the ?march? to octeon2 - the gcc results and wrappers don?t override the setup
> for march flags. This just means that in valgrind - our build results in the FLAG_MIPS64
> getting set to ?-march=mips64? and not in a using a default config with something like
> BR2_mips_64r2=y.

Sorry, but I don't really understand what you say here. So you added
additional MIPS architecture variants (octeon, octeon2, octeon3), and
you were using this new BR2_mips_octeon2=y option. So far so good,
octeon, octeon2 and octeon3 are valid MIPS architecture variants for
gcc (and perhaps it would be good to have them in Buildroot).

However, did you adjust the BR2_GCC_TARGET_ARCH definition in
arch/Config.in.mips to properly associate those MIPS cores to the right
-march option? Indeed you must add something like:

config BR2_GCC_TARGET_ARCH
	...
	default "octeon"	if BR2_mips_octeon
	default "octeon2"	if BR2_mips_octeon2
	default "octeon3"	if BR2_mips_octeon3

This will set --with-arch=octeon2 when building gcc.

Can you try with this? I believe it would be useful to have the Octeon
family supported in Buildroot, as they seem to be quite popular.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com