Menu
▾
▴
valgrind-users
|
From: Jeffrey W. <nol...@gm...> - 2016-08-01 21:35:55
|
Hi Everyone, I'm testing a Raspberry Pi 3. Its ARMv8 using Boradcom A53-based SoC. The SoC is lower end, so its got ASIMD and CRC32, but it lacks PMULL and other Crypto extensions. The gadget ships with a 32-bit Raspbian OS, so its effectively in 32-bit mode. My shell exports CFLAGS and CXXFLAGS, which are tuned for Aarch32: $ echo $CXXFLAGS -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard $ echo $CFLAGS -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard Valgrind appears to have configured successfully: http://pastebin.com/nrenFK1f . Make'ing results in the following. I'm not sure what I should do at the moment. Is this a problem that needs attention? Or am I OK to make install? Thanks in advance. ********** $ make ... Making all in VEX make[2]: Entering directory '/home/valgrind-3.11.0/VEX' make all-am make[3]: Entering directory '/home/valgrind-3.11.0/VEX' gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -I../VEX/pub -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_vanilla=1 -Ipriv -O2 -g -std=gnu99 -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -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 -marm -mcpu=cortex-a8 -Wbad-function-cast -fstrict-aliasing -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard -MT priv/libvex_arm_linux_a-main_globals.o -MD -MP -MF priv/.deps/libvex_arm_linux_a-main_globals.Tpo -c -o priv/libvex_arm_linux_a-main_globals.o `test -f 'priv/main_globals.c' || echo './'`priv/main_globals.c priv/main_globals.c:1:0: warning: switch -mcpu=cortex-a8 conflicts with -march=armv8-a+crc switch ^ ... |
|
From: Jeffrey W. <nol...@gm...> - 2016-08-01 21:52:05
|
On Mon, Aug 1, 2016 at 5:35 PM, Jeffrey Walton <nol...@gm...> wrote: > Hi Everyone, > > I'm testing a Raspberry Pi 3. Its ARMv8 using Boradcom A53-based SoC. > The SoC is lower end, so its got ASIMD and CRC32, but it lacks PMULL > and other Crypto extensions. The gadget ships with a 32-bit Raspbian > OS, so its effectively in 32-bit mode. > > My shell exports CFLAGS and CXXFLAGS, which are tuned for Aarch32: > > $ echo $CXXFLAGS > -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53 > -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard > $ echo $CFLAGS > -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53 > -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard > > Valgrind appears to have configured successfully: http://pastebin.com/nrenFK1f . > > Make'ing results in the following. > > I'm not sure what I should do at the moment. Is this a problem that > needs attention? Or am I OK to make install? For what its worth, it looks like a problem with Autotools: $ ./config.guess armv7l-unknown-linux-gnueabihf Jeff |
|
From: Rob B. <ro...@da...> - 2016-08-02 14:43:50
|
If so, read config.guess - it will tell you how to contribute your architecture to that project. Also, you should be able to work around it by specifying the architecture instead of letting it guess. Look up the ‹build and ‹target flags to configure. On 8/1/16, 4:51 PM, "Jeffrey Walton" <nol...@gm...> wrote: >On Mon, Aug 1, 2016 at 5:35 PM, Jeffrey Walton <nol...@gm...> wrote: >> Hi Everyone, >> >> I'm testing a Raspberry Pi 3. Its ARMv8 using Boradcom A53-based SoC. >> The SoC is lower end, so its got ASIMD and CRC32, but it lacks PMULL >> and other Crypto extensions. The gadget ships with a 32-bit Raspbian >> OS, so its effectively in 32-bit mode. >> >> My shell exports CFLAGS and CXXFLAGS, which are tuned for Aarch32: >> >> $ echo $CXXFLAGS >> -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53 >> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard >> $ echo $CFLAGS >> -DNDEBUG -g2 -O3 -march=armv8-a+crc -mtune=cortex-a53 >> -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard >> >> Valgrind appears to have configured successfully: >>http://pastebin.com/nrenFK1f . >> >> Make'ing results in the following. >> >> I'm not sure what I should do at the moment. Is this a problem that >> needs attention? Or am I OK to make install? > >For what its worth, it looks like a problem with Autotools: > >$ ./config.guess >armv7l-unknown-linux-gnueabihf > >Jeff > >-------------------------------------------------------------------------- >---- >_______________________________________________ >Valgrind-users mailing list >Val...@li... >https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Jeffrey W. <nol...@gm...> - 2016-08-02 14:43:03
|
On Tue, Aug 2, 2016 at 10:28 AM, Rob Boehne <ro...@da...> wrote: > If so, read config.guess - it will tell you how to contribute your > architecture to that project. > Also, you should be able to work around it by specifying the architecture > instead of letting it guess. > Look up the ‹build and ‹target flags to configure. Thanks. Here's what I see: $ ./configure --help `configure' configures Valgrind 3.12.0.SVN to adapt to many kinds of systems. ... Some influential environment variables: CC C compiler command CXX C++ compiler command CFLAGS C compiler flags CXXFLAGS C++ compiler flags ... Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. ... I also tried --target=armv8-a with no joy (even though its a native compile). The flags seem to be ignored by Autotools. Jeff |
|
From: Rob B. <ro...@da...> - 2016-08-02 17:30:16
|
Generic Autotools Advice: 1) modern autotools (last 10 years or more) support setting variables like (CXX) on the command line, after any arguments. This is superior to using the environment because the settings get stored in the logs, which makes for easier debugging. Something like: ../goodie-source/configure —prefix=/opt/goodies CC=“g++ -m64” CFLAGS=“-Wall” 2) Build outside the source tree. Unless the build is broken this will work and keep you from mixing build products with sources. If you want to do that, and pastebin config.log & config.status I’d be happy to look. Another thing you can try is to define the compilers as: CXX=“g++ -march=pentium4 -mtune=i686” (but of course with your ARMish values instead) This will keep things consistent if the CXXFLAGS aren’t added in all the places where they’re needed. On 8/2/16, 9:42 AM, "Jeffrey Walton" <nol...@gm...> wrote: >On Tue, Aug 2, 2016 at 10:28 AM, Rob Boehne <ro...@da...> wrote: >> If so, read config.guess - it will tell you how to contribute your >> architecture to that project. >> Also, you should be able to work around it by specifying the >>architecture >> instead of letting it guess. >> Look up the ‹build and ‹target flags to configure. > >Thanks. Here's what I see: > >$ ./configure --help >`configure' configures Valgrind 3.12.0.SVN to adapt to many kinds of >systems. >... > >Some influential environment variables: > CC C compiler command > CXX C++ compiler command > CFLAGS C compiler flags > CXXFLAGS C++ compiler flags >... > >Use these variables to override the choices made by `configure' or to help >it to find libraries and programs with nonstandard names/locations. >... > >I also tried --target=armv8-a with no joy (even though its a native >compile). > >The flags seem to be ignored by Autotools. > >Jeff |
|
From: Julian S. <js...@ac...> - 2016-08-02 17:26:13
|
> I'm not sure what I should do at the moment. Is this a problem that > needs attention? Or am I OK to make install? Remove the custom CFLAGS and let the build system do its own thing. The binaries it creates do hardware capability autodetection at startup, so all the build system really cares about is whether you're building for arm32 or arm64. The precise variant is irrelevant at build time. J |
Thanks for helping keep SourceForge clean.
X