Closed noloader closed 8 years ago
The code is assuming that if the processor itself is 64-bit then a native 128-bit type must be available via TI mode. I imagine the same issue would arise on SPARCv9 or MIPS64 with a 32-bit userland. Probably using either TI mode or __int128
should be guarded by defined(__SIZEOF_INT128__)
(currently only __int128
is), with TI mode preferred for GCC to avoid -Wpedantic warnings.
Looks good, close it. I'll open another issue if botan_test
has a problem.
Whoops...
...
DLIES ran 144 tests in 209.01 sec all ok
DLIES XOR ran 12 tests all ok
pure virtual method called
terminate called without an active exception
Aborted
That sounds like a compiler bug (to me). Also see Error: pure virtual method called - terminate called without an active exception - Aborted on Stack Overflow (but Botan's code is tight, so I don't expect it to be the case).
...
g++ -pthread -fstack-protector -march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8
-mfloat-abi=hard -fPIC -fvisibility=hidden -std=c++11 -D_REENTRANT -O3 -march=armv8-a
-Wall -Wextra -Wpedantic -Wshadow -Wstrict-aliasing -Wstrict-overflow=5 -Wcast-align -Wmissing-declarations
-Wpointer-arith -Wcast-qual -Wzero-as-null-pointer-constant -Wnon-virtual-dtor -Ibuild/include
-c ./src/lib/mac/poly1305/poly1305.cpp -o build/obj/lib/mac_poly1305.o
g++ -pthread -fstack-protector -march=armv8-a+crc -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8
-mfloat-abi=hard -fPIC -fvisibility=hidden -std=c++11 -D_REENTRANT -O3 -march=armv8-a
-Wall -Wextra -Wpedantic -Wshadow -Wstrict-aliasing -Wstrict-overflow=5 -Wcast-align -Wmissing-declarations
-Wpointer-arith -Wcast-qual -Wzero-as-null-pointer-constant -Wnon-virtual-dtor -Ibuild/include
-c ./src/lib/mac/siphash/siphash.cpp -o build/obj/lib/mac_siphash.o
...
It would be nice to characterize this crash better, it may well be a compiler problem, but botan is made of code and code sometimes has bugs. Is this reproducible and if so can you post a backtrace?
Botan was configured with:
$ ./configure.py --cc=gcc --cpu=armv8-a --cc-abi-flags="-march=armv8-a+crc
-mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard -g3 -O1"
I built GDB 7.11.1 from sources in an attempt to gt something useful. GDB's tip has a few problems, and I have not received the gdb bug tracker notifications that the issues have been fixed. Also, libc-dev is installed.
DLIES ran 144 tests in 211.06 sec all ok
DLIES XOR ran 12 tests all ok
[New Thread 0x76899450 (LWP 6384)]
pure virtual method called
terminate called without an active exception
Thread 2 "botan-test" received signal SIGABRT, Aborted.
[Switching to Thread 0x76899450 (LWP 6384)]
0x768d8f70 in raise () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt full
#0 0x768d8f70 in raise () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0x768da324 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#2 0x00000020 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
@randombit,
I don't feel good about this bug report remaining open. There's a few of reasons.
First, the original issue was resolved. Second, RPI3 tools, like the compiler and debugger, have a number of problems. Third, the RPI3 hardware has some known issues, and it locks ups several times a day.
The tools and the lockups are unique to the RPI3. I have 8 IoT ARM gadgets I test under, and this is the only platform I see the problem.
All-in-all, I would recommend closing this until it can be duplicated on device that does not lock-up, or until the tools catch-up with the platform.
Fair enough, closing.
I testing Master on on a Raspberry Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks PMULL{2} and Crypto extensions, but it includes VMULL and CRC32 (VMULL includes arrangements other than u8). The gadget also runs Raspian, which is a 32-bit OS with hard floats. This is a somewhat unique configuration, and the Raspberry folks probably won't support a true Aarch64 gadget. See ARM NEON programming quick reference for more reading on Aarch32.
Using an ARMv8/Aarch32 configuration for the device results in:
And:
And:
And the preprocessor defines.
__ARM_32BIT_STATE
is particularly important because it signals Aarch32. I'm guessing it can be used to guard the problematic code, if needed.