SIGBUS error while inflate on armv7

[githublulz]

Hello,
I got a SIGBUS error on Android device when inflating compressed data. Any ideas ?
Original zlib inflate function work fine with the same code (without zng_ prefix). Deflate function work also fine with zlib-ng.

Static libs are built with Android NDK with following args :

cmake -B${ABI_BUILD_DIR} \
        -DANDROID_ABI=armeabi-v7a \
	-DWITH_GZFILEOP=OFF \
	-DCMAKE_C_FLAGS="-fdata-sections -ffunction-sections" \
        -DCMAKE_ARCHIVE_OUTPUT_DIRECTORY=${STAGING_DIR}/lib/${ABI} \
        -DANDROID_PLATFORM=android-${MINIMUM_API_LEVEL} \
        -DZLIB_ENABLE_TESTS=OFF \
	-DCMAKE_BUILD_TYPE=Release \
	-DANDROID_TOOLCHAIN=clang \
	-DANDROID_STL=c++_shared \
	-DCMAKE_TOOLCHAIN_FILE=${ANDROID_NDK}/build/cmake/android.toolchain.cmake \
	-DCMAKE_INSTALL_PREFIX=."

Stack-trace :

libc    : Fatal signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0xff9cf895 in tid 16771 (binary), pid 16771 (binary)
04-08 19:45:11.273 16777 16777 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
04-08 19:45:11.273 16777 16777 F DEBUG   : Build fingerprint: 'samsung/a40eea/a40:9'
04-08 19:45:11.273 16777 16777 F DEBUG   : Revision: '4'
04-08 19:45:11.273 16777 16777 F DEBUG   : ABI: 'arm'
04-08 19:45:11.273 16777 16777 F DEBUG   : pid: 16771, tid: 16771, name: binary  >>> ./binary <<<
04-08 19:45:11.273 16777 16777 F DEBUG   : signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0xff9cf895
04-08 19:45:11.274 16777 16777 F DEBUG   :     r0  00000001  r1  00000002  r2  0000002f  r3  ae393ac1
04-08 19:45:11.274 16777 16777 F DEBUG   :     r4  ff9cf897  r5  0000002f  r6  00000002  r7  ff9cef78
04-08 19:45:11.274 16777 16777 F DEBUG   :     r8  ff9cf895  r9  e8d49fec  r10 e92b8d94  r11 ff70da1c
04-08 19:45:11.274 16777 16777 F DEBUG   :     ip  036ff27f  sp  ff9cef50  lr  ae391d3f  pc  ae393b3c
04-08 19:45:11.290 16777 16777 F DEBUG   : 
04-08 19:45:11.290 16777 16777 F DEBUG   : backtrace:
04-08 19:45:11.290 16777 16777 F DEBUG   :     #00 pc 001feb3c  /data/local/tmp/binary (chunkmemset_neon+124)
04-08 19:45:11.290 16777 16777 F DEBUG   :     #01 pc 001fcd3d  /data/local/tmp/binary (zng_inflate_fast+588)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #02 pc 001fc683  /data/local/tmp/binary (zng_inflate+4678)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #03 pc 000810e7  /data/local/tmp/binary (zlibDecompress(unsigned char*, unsigned int, std::__ndk1::vector<char, std::__ndk1::allocator<char>>*)+130)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #04 pc 000813c7  /data/local/tmp/binary (#####+98)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #05 pc 000828e7  /data/local/tmp/binary (#####+1718)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #06 pc 0007a08b  /data/local/tmp/binary (#####+506)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #07 pc 0007c5bd  /data/local/tmp/binary (#####+408)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #08 pc 0007d373  /data/local/tmp/binary (#####1254)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #09 pc 000859a7  /data/local/tmp/binary (#####"+118)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #10 pc 00085bdd  /data/local/tmp/binary (main+92)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #11 pc 0008c34d  /system/lib/libc.so (__libc_init+48)
04-08 19:45:11.291 16777 16777 F DEBUG   :     #12 pc 00072288  /data/local/tmp/binary (_start_main+64)

Code (work fine with original zlib inflate) :

#define DECOMPRESS_CHUNK 16384
int zlibDecompress(unsigned char * compressed, size_t compressedLen, std::vector<char> * decompressed)
{
    int ret;
    unsigned have;
    zng_stream strm;
    unsigned char out[DECOMPRESS_CHUNK];

    size_t alreadyDecompressed = 0;

    /* allocate inflate state */
    strm.zalloc = Z_NULL;
    strm.zfree = Z_NULL;
    strm.opaque = Z_NULL;
    strm.avail_in = 0;
    strm.next_in = Z_NULL;
    ret = zng_inflateInit(&strm);
    if (ret != Z_OK)
        return ret;

    /* decompress until deflate stream ends or end of file */
    do {
        if (alreadyDecompressed + DECOMPRESS_CHUNK > compressedLen)
            strm.avail_in = compressedLen % DECOMPRESS_CHUNK;
        else
            strm.avail_in = DECOMPRESS_CHUNK;

        if (strm.avail_in == 0)
            break;

        strm.next_in = compressed + alreadyDecompressed;

        /* run inflate() on input until output buffer not full */
        do {
            strm.avail_out = DECOMPRESS_CHUNK;
            strm.next_out = out;
            ret = zng_inflate(&strm, Z_NO_FLUSH);

            if (ret == Z_STREAM_ERROR) {
                printf("zlibDecompress: Internal error");
                return Z_STREAM_ERROR;
            }
            switch (ret) {
                case Z_NEED_DICT:
                    ret = Z_DATA_ERROR;     /* and fall through */
                case Z_DATA_ERROR:
                case Z_MEM_ERROR:
                    (void)zng_inflateEnd(&strm);
                    return ret;
            }
            have = DECOMPRESS_CHUNK - strm.avail_out;
            decompressed->insert(decompressed->end(), out, out+have);

        } while (strm.avail_out == 0);

        alreadyDecompressed += DECOMPRESS_CHUNK;
        /* done when inflate() says it's done */

        if (strm.avail_in != DECOMPRESS_CHUNK)
            break;

    } while (ret != Z_STREAM_END);

    /* clean up and return */
    (void)zng_inflateEnd(&strm);
    return ret == Z_STREAM_END ? Z_OK : Z_DATA_ERROR;
}

[Dead2]

Some more information I think we would like to see here:

• What version of zlib-ng is this? Is it one of the release tarballs and what commit?
• Please copy-paste the output of the CMake command, it lets us know a bit more about how zlib-ng was compiled for your platform.

I also just merged a few fixes into develop, one of them concerning arm floatingpoint, so testing with that (or without if this was already with that) might be worth it. This crash is in neon code, so it might be relevant.
And what happens if you build and run the tests?

[Dead2]

Oh, sorry, the fixes I was thinking about are still in #918, they almost made it into develop earlier.

[mtl1979]

BUS_ADRALN means alignment violation. We can diagnose more after we see the cmake output...

[githublulz]

It's zlib-ng version 2.0.2 and code is from git tag 2.0.2.

Cmake output :

-- Using CMake version 3.10.2
-- ZLIB_HEADER_VERSION: 1.2.11
-- ZLIBNG_HEADER_VERSION: 2.0.2
-- The C compiler identification is Clang 11.0.5
-- Check for working C compiler: /opt/android-ndk-r22/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
-- Check for working C compiler: /opt/android-ndk-r22/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Arch detected: 'armv7-none-linux-androideabi23'
-- Basearch of 'armv7-none-linux-androideabi23' has been detected as: 'arm'
-- Using CMake toolchain: /opt/android-ndk-r22/build/cmake/android.toolchain.cmake
-- ARM floating point arch: 
-- Performing Test MFPU_NEON_AVAILABLE
-- Performing Test MFPU_NEON_AVAILABLE - Success
-- Architecture supports unaligned reads
-- Architecture supports unaligned reads of > 4 bytes
-- Looking for stdarg.h
-- Looking for stdarg.h - found
-- Looking for sys/sdt.h
-- Looking for sys/sdt.h - not found
-- Looking for unistd.h
-- Looking for unistd.h - found
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of off64_t
-- Check size of off64_t - done
-- Looking for fseeko
-- Looking for fseeko - found
-- Looking for strerror
-- Looking for strerror - found
-- Performing Test HAVE_NO_INTERPOSITION
-- Performing Test HAVE_NO_INTERPOSITION - Success
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_HIDDEN
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_INTERNAL
-- Performing Test HAVE_ATTRIBUTE_VISIBILITY_INTERNAL - Success
-- Performing Test HAVE_BUILTIN_CTZ
-- Performing Test HAVE_BUILTIN_CTZ - Success
-- Performing Test HAVE_BUILTIN_CTZLL
-- Performing Test HAVE_BUILTIN_CTZLL - Success
-- Performing Test HAVE_PTRDIFF_T
-- Performing Test HAVE_PTRDIFF_T - Success
-- Architecture-specific source files: arch/arm/armfeature.c;arch/arm/crc32_acle.c;arch/arm/insert_string_acle.c;arch/arm/adler32_neon.c;arch/arm/chunkset_neon.c;arch/arm/slide_neon.c
-- The following features have been enabled:

 * CMAKE_BUILD_TYPE, Build type: Release (selected)
 * WITH_OPTIM, Build with optimisation
 * WITH_NEW_STRATEGIES, Use new strategies
 * WITH_UNALIGNED, Support unaligned reads on platforms that support it
 * WITH_ACLE, Build with ACLE
 * WITH_NEON, Build with NEON intrinsics
 * ACLE_CRC, Support ACLE optimized CRC hash generation, using "-march=armv8-a+crc"
 * NEON_ADLER32, Support NEON instructions in adler32, using "-mfpu=neon"
 * NEON_SLIDEHASH, Support NEON instructions in slide_hash, using "-mfpu=neon"

-- The following features have been disabled:

 * WITH_GZFILEOP, Compile with support for gzFile related functions
 * ZLIB_COMPAT, Compile with zlib compatible API
 * ZLIB_ENABLE_TESTS, Build test binaries
 * ZLIB_DUAL_LINK, Dual link tests against system zlib
 * WITH_SANITIZER, Build with sanitizer (Memory, Address, Undefined)
 * WITH_FUZZERS, Build test/fuzz
 * WITH_NATIVE_INSTRUCTIONS, Instruct the compiler to use the full instruction set on this host (gcc/clang -march=native)
 * WITH_MAINTAINER_WARNINGS, Build with project maintainer warnings
 * WITH_CODE_COVERAGE, Enable code coverage reporting
 * WITH_INFLATE_STRICT, Build with strict inflate distance checking
 * WITH_INFLATE_ALLOW_INVALID_DIST, Build with zero fill for inflate invalid distances
 * INSTALL_UTILS, Copy minigzip and minideflate during install

-- Configuring done
-- Generating done

Make build output :

Scanning dependencies of target zlib
Scanning dependencies of target zlibstatic
[  1%] Building C object CMakeFiles/zlib.dir/adler32.c.o
[  3%] Building C object CMakeFiles/zlibstatic.dir/chunkset.c.o
[  5%] Building C object CMakeFiles/zlibstatic.dir/adler32.c.o
[  7%] Building C object CMakeFiles/zlib.dir/chunkset.c.o
[  9%] Building C object CMakeFiles/zlib.dir/compare258.c.o
[ 11%] Building C object CMakeFiles/zlibstatic.dir/compress.c.o
[ 12%] Building C object CMakeFiles/zlibstatic.dir/compare258.c.o
[ 14%] Building C object CMakeFiles/zlib.dir/compress.c.o
[ 16%] Building C object CMakeFiles/zlibstatic.dir/crc32.c.o
[ 18%] Building C object CMakeFiles/zlibstatic.dir/crc32_comb.c.o
[ 20%] Building C object CMakeFiles/zlib.dir/crc32.c.o
[ 22%] Building C object CMakeFiles/zlibstatic.dir/deflate.c.o
[ 24%] Building C object CMakeFiles/zlibstatic.dir/deflate_fast.c.o
[ 25%] Building C object CMakeFiles/zlib.dir/crc32_comb.c.o
[ 27%] Building C object CMakeFiles/zlib.dir/deflate.c.o
[ 29%] Building C object CMakeFiles/zlibstatic.dir/deflate_medium.c.o
[ 31%] Building C object CMakeFiles/zlib.dir/deflate_fast.c.o
[ 33%] Building C object CMakeFiles/zlibstatic.dir/deflate_quick.c.o
[ 35%] Building C object CMakeFiles/zlib.dir/deflate_medium.c.o
[ 37%] Building C object CMakeFiles/zlibstatic.dir/deflate_slow.c.o
[ 38%] Building C object CMakeFiles/zlibstatic.dir/functable.c.o
[ 40%] Building C object CMakeFiles/zlib.dir/deflate_quick.c.o
[ 42%] Building C object CMakeFiles/zlibstatic.dir/infback.c.o
[ 44%] Building C object CMakeFiles/zlibstatic.dir/inffast.c.o
[ 46%] Building C object CMakeFiles/zlib.dir/deflate_slow.c.o
[ 48%] Building C object CMakeFiles/zlibstatic.dir/inflate.c.o
[ 50%] Building C object CMakeFiles/zlib.dir/functable.c.o
[ 51%] Building C object CMakeFiles/zlibstatic.dir/inftrees.c.o
[ 53%] Building C object CMakeFiles/zlib.dir/infback.c.o
[ 55%] Building C object CMakeFiles/zlib.dir/inffast.c.o
[ 57%] Building C object CMakeFiles/zlibstatic.dir/insert_string.c.o
[ 59%] Building C object CMakeFiles/zlibstatic.dir/trees.c.o
[ 61%] Building C object CMakeFiles/zlib.dir/inflate.c.o
[ 62%] Building C object CMakeFiles/zlibstatic.dir/uncompr.c.o
[ 64%] Building C object CMakeFiles/zlib.dir/inftrees.c.o
[ 66%] Building C object CMakeFiles/zlib.dir/insert_string.c.o
[ 68%] Building C object CMakeFiles/zlibstatic.dir/zutil.c.o
[ 70%] Building C object CMakeFiles/zlib.dir/trees.c.o
[ 72%] Building C object CMakeFiles/zlibstatic.dir/arch/arm/armfeature.c.o
[ 74%] Building C object CMakeFiles/zlibstatic.dir/arch/arm/crc32_acle.c.o
[ 75%] Building C object CMakeFiles/zlibstatic.dir/arch/arm/insert_string_acle.c.o
[ 77%] Building C object CMakeFiles/zlibstatic.dir/arch/arm/adler32_neon.c.o
[ 79%] Building C object CMakeFiles/zlibstatic.dir/arch/arm/chunkset_neon.c.o
[ 81%] Building C object CMakeFiles/zlibstatic.dir/arch/arm/slide_neon.c.o
[ 83%] Building C object CMakeFiles/zlib.dir/uncompr.c.o
[ 85%] Building C object CMakeFiles/zlib.dir/zutil.c.o
[ 87%] Building C object CMakeFiles/zlib.dir/arch/arm/armfeature.c.o
[ 90%] Building C object CMakeFiles/zlib.dir/arch/arm/crc32_acle.c.o
[ 90%] Building C object CMakeFiles/zlib.dir/arch/arm/insert_string_acle.c.o
[ 92%] Linking C static library staging/lib/armeabi-v7a/libz-ng.a
[ 94%] Building C object CMakeFiles/zlib.dir/arch/arm/adler32_neon.c.o
[ 96%] Building C object CMakeFiles/zlib.dir/arch/arm/chunkset_neon.c.o
[ 98%] Building C object CMakeFiles/zlib.dir/arch/arm/slide_neon.c.o
[ 98%] Built target zlibstatic
[100%] Linking C shared library libz-ng.so
[100%] Built target zlib

[mtl1979]

Because it's alignment violation, we also need disassembly of the function chunkmemset_neon so we know the exact instruction (and line in source code) that causes the alignment violation.

Most of the code in chunkmemset_neon already use 8-bit wide reads and writes but obviously there is still some wider reads and writes using for example general-purpose registers.

[githublulz]

Here the disassembly of the function chunkmemset_neon :
Do you need the complete object file ?

00000000 <chunkmemset_neon>:
   0:	b5f0      	push	{r4, r5, r6, r7, lr}
   2:	af03      	add	r7, sp, #12
   4:	e92d 07f0 	stmdb	sp!, {r4, r5, r6, r7, r8, r9, sl}
   8:	9201      	str	r2, [sp, #4]
   a:	4604      	mov	r4, r0
   c:	4844      	ldr	r0, [pc, #272]	; (120 <chunkmemset_neon+0x120>)
   e:	460e      	mov	r6, r1
  10:	2a0f      	cmp	r2, #15
  12:	4478      	add	r0, pc
  14:	f8d0 a000 	ldr.w	sl, [r0]
  18:	f8da 0000 	ldr.w	r0, [sl]
  1c:	9003      	str	r0, [sp, #12]
  1e:	9102      	str	r1, [sp, #8]
  20:	d808      	bhi.n	34 <chunkmemset_neon+0x34>
  22:	4270      	negs	r0, r6
  24:	5c21      	ldrb	r1, [r4, r0]
  26:	7021      	strb	r1, [r4, #0]
  28:	3401      	adds	r4, #1
  2a:	9901      	ldr	r1, [sp, #4]
  2c:	3901      	subs	r1, #1
  2e:	9101      	str	r1, [sp, #4]
  30:	d1f8      	bne.n	24 <chunkmemset_neon+0x24>
  32:	e040      	b.n	b6 <chunkmemset_neon+0xb6>
  34:	1e70      	subs	r0, r6, #1
  36:	eba4 0806 	sub.w	r8, r4, r6
  3a:	4615      	mov	r5, r2
  3c:	2807      	cmp	r0, #7
  3e:	d808      	bhi.n	52 <chunkmemset_neon+0x52>
  40:	e8df f000 	tbb	[pc, r0]
  44:	1f0c1c04 	.word	0x1f0c1c04
  48:	220c0c0c 	.word	0x220c0c0c
  4c:	f9e8 0c2f 	vld1.8	{d16[]-d17[]}, [r8]
  50:	e01e      	b.n	90 <chunkmemset_neon+0x90>
  52:	2e10      	cmp	r6, #16
  54:	d102      	bne.n	5c <chunkmemset_neon+0x5c>
  56:	f968 0a0f 	vld1.8	{d16-d17}, [r8]
  5a:	e019      	b.n	90 <chunkmemset_neon+0x90>
  5c:	2e0f      	cmp	r6, #15
  5e:	d835      	bhi.n	cc <chunkmemset_neon+0xcc>
  60:	1960      	adds	r0, r4, r5
  62:	f1a0 0901 	sub.w	r9, r0, #1
  66:	42b5      	cmp	r5, r6
  68:	d944      	bls.n	f4 <chunkmemset_neon+0xf4>
  6a:	4620      	mov	r0, r4
  6c:	4641      	mov	r1, r8
  6e:	4632      	mov	r2, r6
  70:	464b      	mov	r3, r9
  72:	f7ff fffe 	bl	0 <chunkmemset_neon>
  76:	4604      	mov	r4, r0
  78:	1bad      	subs	r5, r5, r6
  7a:	e7f4      	b.n	66 <chunkmemset_neon+0x66>
  7c:	f9e8 0c7f 	vld1.16	{d16[]-d17[]}, [r8 :16] <-- (chunkmemset_neon+124) ?
  80:	e006      	b.n	90 <chunkmemset_neon+0x90>
  82:	f9e8 0cbf 	vld1.32	{d16[]-d17[]}, [r8 :32]
  86:	e003      	b.n	90 <chunkmemset_neon+0x90>
  88:	f968 070f 	vld1.8	{d16}, [r8]
  8c:	ef60 11b0 	vorr	d17, d16, d16
  90:	f025 000f 	bic.w	r0, r5, #15
  94:	4240      	negs	r0, r0
  96:	b118      	cbz	r0, a0 <chunkmemset_neon+0xa0>
  98:	f944 0a0d 	vst1.8	{d16-d17}, [r4]!
  9c:	3010      	adds	r0, #16
  9e:	e7fa      	b.n	96 <chunkmemset_neon+0x96>
  a0:	2000      	movs	r0, #0
  a2:	f015 050f 	ands.w	r5, r5, #15
  a6:	9001      	str	r0, [sp, #4]
  a8:	d004      	beq.n	b4 <chunkmemset_neon+0xb4>
  aa:	4620      	mov	r0, r4
  ac:	4641      	mov	r1, r8
  ae:	462a      	mov	r2, r5
  b0:	f7ff fffe 	bl	0 <__aeabi_memcpy>
  b4:	442c      	add	r4, r5
  b6:	f8da 0000 	ldr.w	r0, [sl]
  ba:	9903      	ldr	r1, [sp, #12]
  bc:	4288      	cmp	r0, r1
  be:	bf01      	itttt	eq
  c0:	4620      	moveq	r0, r4
  c2:	b004      	addeq	sp, #16
  c4:	e8bd 0700 	ldmiaeq.w	sp!, {r8, r9, sl}
  c8:	bdf0      	popeq	{r4, r5, r6, r7, pc}
  ca:	e027      	b.n	11c <chunkmemset_neon+0x11c>
  cc:	a902      	add	r1, sp, #8
  ce:	aa01      	add	r2, sp, #4
  d0:	4620      	mov	r0, r4
  d2:	f7ff fffe 	bl	0 <chunkmemset_neon>
  d6:	e9dd 2101 	ldrd	r2, r1, [sp, #4]
  da:	f8da 3000 	ldr.w	r3, [sl]
  de:	9c03      	ldr	r4, [sp, #12]
  e0:	42a3      	cmp	r3, r4
  e2:	d11b      	bne.n	11c <chunkmemset_neon+0x11c>
  e4:	1a41      	subs	r1, r0, r1
  e6:	b004      	add	sp, #16
  e8:	e8bd 0700 	ldmia.w	sp!, {r8, r9, sl}
  ec:	e8bd 40f0 	ldmia.w	sp!, {r4, r5, r6, r7, lr}
  f0:	f7ff bffe 	b.w	0 <chunkmemset_neon>
  f4:	2d00      	cmp	r5, #0
  f6:	9501      	str	r5, [sp, #4]
  f8:	d0dd      	beq.n	b6 <chunkmemset_neon+0xb6>
  fa:	f8da 0000 	ldr.w	r0, [sl]
  fe:	9903      	ldr	r1, [sp, #12]
 100:	4288      	cmp	r0, r1
 102:	bf01      	itttt	eq
 104:	4620      	moveq	r0, r4
 106:	4641      	moveq	r1, r8
 108:	462a      	moveq	r2, r5
 10a:	464b      	moveq	r3, r9
 10c:	bf01      	itttt	eq
 10e:	b004      	addeq	sp, #16
 110:	e8bd 0700 	ldmiaeq.w	sp!, {r8, r9, sl}
 114:	e8bd 40f0 	ldmiaeq.w	sp!, {r4, r5, r6, r7, lr}
 118:	f7ff bffe 	beq.w	0 <chunkmemset_neon>
 11c:	f7ff fffe 	bl	0 <__stack_chk_fail>
 120:	0000010a 	.word	0x0000010a

[mtl1979]

Looking at the disassembly, I think chunkmemset_2 and chunkmemset_4 need temporary variable because NEON doesn't support unaligned loads wider than 8 bits under ARMv7 and earlier.

[nmoinvaz]

I think user should be using cmake . -DUNALIGNED_OK=OFF and then we have to add UNALIGNED_OK support into chunkset_neon.c. This is similar to how chunkset.c works.

[mtl1979]

@nmoinvaz UNALIGNED_OK is only used for general-purpose integer registers, not for floating point or vector registers. Not forgetting that it should be detected by the build system, not specified by the user.

[githublulz]

Your fix works great. Thank you !

[NiLuJe]

This appears to be a Clang code generation quirk?

• According to Table A3-1 Alignment requirements of load/store instructions in the ARM DDI 0406C PDF, if unaligned accesses are allowed by the CPU, this (e.g., the alignment check is element sized, so, here, at worst, that's int32, which is just fine for an unaligned access on 32-bit) is perfectly sane... as long as there are no :align hints!

And therein lies the rub:

Clang appears to generate said align hints, despite that assumption being a tad optimistic. I checked w/ a plain Linux build targeting the Cortex A9 on Clang 11, and I'm seeing similar assembly as the reporter:

e.g.,

vld1.16>{d16[]-d17[]}, [r6 :16]
&
vld1.32 {d16[]-d17[]}, [r8 :32]

And that does implode at runtime (even the kernel fixup can't deal with it).

But, with GCC (tested w/ 7.5 & 10.3), I get no :align hints, and the CPU deals with it all on its loneseome:

vld1.32>{d16[]-d17[]}, [r5]
vld1.16>{d16[]-d17[]}, [r5]

[mtl1979]

gcc is usually "smart" enough to ignore casts using unnamed "temporary" variables. On the other hand clang thinks casts with unnamed variables are supposed to be explicit and as such doesn't ignore them. C standard itself doesn't allow unaligned named variables.

In later compiler versions using named "temporary" variables can cause compiler warnings if the variable scope extends past end of declaring function. This is pretty much only case I know when unnamed "temporary" variables must be used.

[NiLuJe]

Most of this flies waaay too far above my head, just wanted to point out that the previous iteration "works" w/ current GCC versions (as long as the CPU actually handles unaligned accesses) ;).

[mtl1979]

There is quite a lot of workarounds for compilers that try to be too standards conforming or too smart... I've seen code that works correctly with optimizations enabled, but craps the shit out if optimizations are disabled.