How to enable Aarch32 instruction set on ARMv8-a? - gcc

Raspberry Pi 3 uses a Broadcom SoC with and ARMv8 A53 core. It also uses a 32-bit OS based on Debian Jessie. According to ARM's ARM NEON programming quick reference, Section 3.2, Instruction set:
The ARMv8-A AArch32 instruction set consists of A32 (ARM instruction set, a 32-bit fixed length instruction set) and T32 (Thumb instruction set, a 16-bit fixed length instruction set; Thumb2 instruction set, 16 or 32-bit length instruction set). It is a superset of the ARMv7-A instruction set, so that it retains the backwards compatibility necessary to run existing software. There are some additions to A32 and T32 to maintain alignment with the A64 instruction set, including NEON division, and the Cryptographic Extension instructions. NEON double precision floating point (IEEE compliance) is also supported.
I kind of asked a similar question a while back on the GCC mailing list at How to test Aarch32 execution environment on Aarch64? But I did not quite understand the answer:
Once you're compiling with an arm toolchain the CRC extension can be enabled through -march=armv8-a+crc or selecting an -mcpu option that enables it. To enable the Crypto extension you'll have to specify the right -mfpu option.
My question is simple... How do I enable both CRC and Crypto extensions for the Raspberry Pi 3?
Here are some attempts that don't work.
Attempt (4) is similar to how we do it natively under Aarch64: gcc -march=armv8-a+crc+crypto -mtune=cortex-a53. Attempt (5) actually enables CRC, but I can't seem to get anything else enabled, like PMULL, PMULL2, AES, SHA1 and SHA2.
gcc -D__ARM_FEATURE_CRYPTO -D__ARM_FEATURE_CRC -march=armv8-a+crc+crypto -mcpu=cortex-a53 -mfpu=neon test.cc -o test.exe
gcc -D__ARM_FEATURE_CRYPTO -D__ARM_FEATURE_CRC -march=armv8-a+crc -mcpu=cortex-a53 -mfpu=neon test.cc -o test.exe
gcc -D__ARM_FEATURE_CRYPTO -D__ARM_FEATURE_CRC -march=armv8-a -mcpu=cortex-a53 -mfpu=neon test.cc -o test.exe
gcc -march=armv8-a+crc+crypto -mcpu=cortex-a53 -mfpu=neon test.cc -o test.exe
gcc -march=armv8-a+crc -mcpu=cortex-a53 -mfpu=neon test.cc -o test.exe
gcc -march=armv8-a -mcpu=cortex-a53 -mfpu=neon test.cc -o test.exe
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.9.2 (Raspbian 4.9.2-10)

Quite simply, "the right -mfpu option" should be -mfpu=crypto-neon-fp-armv8.

Related

warnings while trying to compile old linux kernel with gcc 12.1.0

I am currently hunting a bug using git bisect in linux staging-testing tree.
Some commits are giving following errors after I try to build them:
subcmd-util.h:58:31: error: pointer may be used after ‘realloc’ [-Werror=use-after-free]
58 | ret = realloc(ptr, 1);
check.c:2867:58: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 9 [-Werror=format-truncation=]
2867 | snprintf(pvname, sizeof(pvname), "pv_ops[%d]", idx);
I tried adding -Wno-error=use-after-free to KBUILD_FLAGS in main Makefile, tried adding
KBUILD_CFLAGS += $(call cc-disable-warning, use-after-free)
I even tried removing -Werror from CFLAGS in Makefile in folder where problematic files are located, but nothing worked.
More information:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.artixlinux.org/ --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)
Linux staging tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git.
One of the commits that gives following warnings: 2ab9c9675fe892e7fe9fa8c0a6125e2b40d2889d.
To compile older version of kernel I needed older compiler ("Linux kernel sources are in general not forward-compatible with new compilers"). In my case the kernel version was 5.16.0 and I could compile it with gcc 11. If you have gcc 11 specific warnings then try gcc 10 and so on.
Except CC flags, I also needed set to HOSTCC flags to use gcc-11 compiler:
make HOSTCC=gcc-11 CC=gcc-11

GCC built out ELF64 binary but cannot execute binary file: Exec format error

I met strange issues about ELF32/ELF64 format in my building machine.
Both applications and kernle module don't work.
For applications (such as helloworld program), it can be built out to ELF64 but run failed.
For kernel modules it will always be built out to ELF32 format even if append -march=x86-64 to CFLGAS, which leads to Module has invalid ELF structures issue when insmoding.
If append -m64 and it will lead to cc1: error: CPU you selected does not support x86-64 instruction set
I guess when the first question fixed, the next will also be fixed, so I only post the first one here.
Ubunt 18.04, gcc 7.5.0 , x86_64 PC
GCC built out helloworld program to ELF64 binary but cannot run
gcc -o hello -v -c hello.c
...
chmod +x hello
./hello
-bash: ./hello: cannot execute binary file: Exec format error
uname -a
Linux AELAB146 5.4.0-74-generic #83~18.04.1-Ubuntu SMP Tue May 11 16:01:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
Kernel Module's Makefile
EXTRA_CFLAGS += -Wall (and others blablabla) -m64
KERNEL_BUILD ?= /lib/modules/$(shell uname -r)/build
pcie_objs := common/init.o common/pcie.o common/net.o platform.o
obj-m := pcie.o
pcie.o: $(pcie_objs)
ld -r $^ -o $#
all:
make -C $(KERNEL_BUILD) M=$(PWD) V=1 modules
I'v no idea about why it's so long for the gcc Configured options in my system.
You're not supposed to pass -c to GCC when building an executable. It means to compile and not link, but programs need to be linked to be ran. The fact that you had to do chmod +x hello should have been a clue that you were doing something very wrong. Run gcc -o hello -v hello.c and then ./hello.
I assume your issue with kernel modules is similarly caused by an incorrect command line, but since you didn't post the command line you used for it, I can't see where you went wrong with it.

g++ 9.2.1 on modern Intel: any way at all to get CMPXCHG16B instructions generated from C++11 atomic<> or C11 atomic_compare_exchange_strong

I simply want an instruction, not a library call, for speed when I'm using atomic<> with 16-byte types.
Duh: the main reason anyone uses atomic<> with 16-byte types is surely for speed!
The man page is teasing me:
-mcx16
This option enables GCC to generate "CMPXCHG16B" instructions in 64-bit code to implement compare-and-exchange operations on 16-byte aligned 128-bit objects. This is useful for atomic updates of data structures exceeding one machine word in size. The compiler uses this instruction to implement __sync Builtins. However, for __atomic Builtins operating on 128-bit integers, a library call is always used.
I'd even welcome an assembly version, though for odd reasons I'm using C11, not C++11. (A C++11 solution would certainly be welcome enough though!)
This is my compiler:
> g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)

gcc compilation issue

I am trying to compile but getting following error message. I tried to search into google
but was not able to figure out the solution.
Creating qmake. Please wait...
g++ -c -o project.o -m64 -pipe -DQMAKE_OPENSOURCE_EDITION -I. -Igenerators
-Igenerators/unix -Igenerators/win32 -Igenerators/mac -I/tmp/qt-x11-opensource-src-4.2.3
/src/corelib/arch/generic -I/tmp/qt-x11-opensource-src-4.2.3/include -I/tmp/qt-x11-opensource-src-4.2.3/include/QtCore -I/tmp/qt-x11-opensource-src-4.2.3/include -I/tmp/qt-x11-opensource-src-4.2.3/include/QtCore -I/tmp/qt-x11-opensource-src-4.2.3/src/corelib/global -I/tmp/qt-x11-opensource-src-4.2.3/src/3rdparty/md5 -DQT_NO_TEXTCODEC -DQT_NO_UNICODETABLES -DQT_NO_COMPONENT -DQT_NO_STL -DQT_BUILD_QMAKE -DQT_NO_COMPRESS -I/tmp/qt-x11-opensource-src-4.2.3/mkspecs/linux-g++-64 -DHAVE_QCONFIG_CPP -DQT_NO_THREAD -DQT_NO_QOBJECT -DQT_NO_GEOM_VARIANT project.cpp
project.cpp:1: sorry, unimplemented: 64-bit mode not compiled in
gmake: *** [project.o] Error 1
machine name
Linux #1 SMP Sun May 10 18:54:51 MSD 2009 x86_64 x86_64 x86_64 GNU/Linux
g++ -v
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)
You're trying to compile your program using the -m64 switch when your version of g++ was probably compiled without the 64-bit flag.
Your gcc is compiled for 32 bit mode and you are trying to compile your code for 64 bit mode.
Looks like your compiler doesn't support 64 bit memory model.
You may try without -m64 parameter, or install 64-version of the gcc.

-static option for gcc?

I'm wondering what the -static option on gcc does. I need this option when compiling a certain application, however when I do I get the following error:
gcc -static -O3 -o prog prog.c
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
What needs installation?
GCC version:
[user#localhost dir]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC)
The -static option links a program statically, in other words it does not require a dependency on dynamic libraries at runtime in order to run.
To achieve static linking requires that the archive (.a) versions of your libraries exist on the system. so /usr/lib/libc.a, /usr/lib/crt1.o, etc.
On modern linux systems (as you are using red hat): when a binary links together it 1) either puts the code into the executable via .o and .a files, or 2) puts in references to dynamic libraries (.so) files that is resolved by /lib/ld-linux.so (or /lib64/ld-linux=x86-64.so) which is always at a well known place.
For your particular system, if a program is specifically looking to create a static version of itself then you need to install the static versions of your devel tools. You need, at the minimum, glibc-static package. You may also need libstdc++-static package as well.
The -static flag forces the linker to accept only static libraries and not any shared libraries.
If you want to use -static, you have to ensure that you have a static version of the C library installed, which might be tricky to find (most systems do not have a static C library any more). Or you have to cancel the effect of -static. However, in the example, that would defeat the purpose of -static since the only library linked is (implicitly) the C library.
On systems that support dynamic linking, this overrides -pie and prevents linking with the shared libraries. On other systems, this option has no effect.
Ref: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

Resources