LVGL tests produce unaligned code, fail to build
Description
The LVGL tests, on Cortex-M0+ CPUs (eg. samr21-xpro), fail to build with an address alignment error.
The error message is not helpful.
CI didn't catch this. (Even though it also occurs with RIOT_CI_BUILD=1, which I've stopped taking for granted).
Steps to reproduce the issue
On current master (0c6d696d102e1d075fe0c0beca710b6fd4f901a5), run:
$ BOARD="samr21-xpro" make all -C tests/pkg/lvgl BUILD_IN_DOCKER=1
[...]
"make" -C /data/riotbuild/riotbase/pkg/cmsis/
"make" -C /data/riotbuild/riotbase/pkg/lvgl/
"make" -C /data/riotbuild/riotbase/build/pkg/lvgl/src/core -f /data/riotbuild/riotbase/pkg/lvgl/Makefile.lvgl_module MODULE=lvgl_core
/tmp/ccjgRjHK.s: Assembler messages:
/tmp/ccjgRjHK.s: Error: unaligned opcodes detected in executable segment
make[2]: *** [/data/riotbuild/riotbase/Makefile.base:146: /data/riotbuild/riotbase/tests/pkg/lvgl/bin/samr21-xpro/lvgl_core/lv_event.o] Error 1
Progress drilling it down
Curiously, ./build/pkg/lvgl/src/core/lv_event.c contains no assembly and no manual alignment (at least not any that can be found when grepping in that file). So: WAT?
Versions
Current master is 0c6d696d102e1d075fe0c0beca710b6fd4f901a5, riotdocker was freshly pulled and is now a3f04669cc049f12df754fa80744715f8e71a501654efa85d929d1e997384786
Curiously, this does not trigger when I'm not building in docker (on Debian sid), which has:
Host system print-versions
Operating System Environment
----------------------------
Operating System: "Debian GNU/Linux"
Kernel: Linux 6.5.0-4-amd64 x86_64 unknown
System shell: /usr/bin/dash (probably dash)
make's shell: /usr/bin/dash (probably dash)
Installed compiler toolchains
-----------------------------
native gcc: gcc (Debian 13.2.0-6) 13.2.0
arm-none-eabi-gcc: arm-none-eabi-gcc (15:12.2.rel1-1) 12.2.1 20221205
avr-gcc: avr-gcc (GCC) 5.4.0
msp430-elf-gcc: missing
riscv-none-elf-gcc: missing
riscv64-unknown-elf-gcc: riscv64-unknown-elf-gcc (12.2.0-14+11+b1) 12.2.0
riscv-none-embed-gcc: missing
riscv32-esp-elf-gcc: missing
xtensa-esp32-elf-gcc: missing
xtensa-esp32s2-elf-gcc: missing
xtensa-esp32s3-elf-gcc: missing
xtensa-esp8266-elf-gcc: missing
clang: Debian clang version 16.0.6 (17)
Installed compiler libs
-----------------------
arm-none-eabi-newlib: "3.3.0"
msp430-elf-newlib: missing
riscv-none-elf-newlib: missing
riscv64-unknown-elf-newlib: missing
riscv-none-embed-newlib: missing
riscv32-esp-elf-newlib: missing
xtensa-esp32-elf-newlib: missing
xtensa-esp32s2-elf-newlib: missing
xtensa-esp32s3-elf-newlib: missing
xtensa-esp8266-elf-newlib: missing
avr-libc: "2.0.0" ("20150208")
Installed development tools
---------------------------
ccache: ccache version 4.8.3
cmake: cmake version 3.27.7
cppcheck: Cppcheck 2.12.0
doxygen: 1.9.8
git: git version 2.42.0
make: GNU Make 4.3
openocd: Open On-Chip Debugger 0.12.0
python: Python 2.7.18
python2: Python 2.7.18
python3: Python 3.11.6
flake8: 5.0.4 (mccabe: 0.7.0, pycodestyle: 2.10.0, pyflakes: 2.5.0) CPython 3.11.6 on
coccinelle: missing
Looking outside RIOT (previous checks for duplicate bugs were only made here), this has been seen in LVGL time and again, and closed there as a compiler bug:
I'll close this as I don't think we can do much on our end to fix it, unless we avoided switch cases with over 16 statements.
So ... how do we get our arm-none-eabi-gcc up to 12.2.1 (which works on the host) vs. the 10.3.1 in riotdocker? Probably waiting for the next riotdocker distro upgrade.
As that'll take time: What's the good workaround, and why do our nightlies even pass?
Kaspar commented that possibly Murdock may not run with -Os. If that is so, "don't use -Os" might be the workaround we use until 12.2.1 comes in when we go for Ubuntu Noble (which will be 24.04 LTS in possibly less time than it'd take to establish a different workaround).
This packages has:
# fix "cast increases required alignment of target type" raised from a header file
CFLAGS += -Wno-cast-align
This is now the 2nd pkg I'm looking at this weekend that had real alignment errors that -Wcast-align would have caught. I can try to take a look.