[Bug c/101188] New: [AVR] Miscompilation and function pointers
joel.bertrand at systella dot fr
gcc-bugzilla@gcc.gnu.org
Thu Jun 24 07:36:26 GMT 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Bug ID: 101188
Summary: [AVR] Miscompilation and function pointers
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joel.bertrand at systella dot fr
Target Milestone: ---
Hello,
I'm writing a firmware that runs on an ATmega1284. To build this bare metal
firmware, I have used avr-gcc 5.4.0 and I have seen a strange pointer
corruption. Thus, I have built from scratch a new gcc (11.1.0) that triggers
the same bug.
In a first time, my code is downloadable at
https://hilbert.systella.fr/public/firmware.tar.gz
I have tried to make a simple testcase, but when I remove some unused code,
sometimes, firmware runs as expected. That being said, a lot of code is not
executed. In main.c, I only initialize my board and I only try to send LoRaWAN
packets.
In lorawan/ldl_mac.c, you will find the following code :
#if defined(LDL_FIX_GCC_BUG)
void app_handler(void *app, enum ldl_mac_response_type type,
const union ldl_mac_response_arg *arg);
if (self->handler != app_handler) for(;;);
#endif
self->handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, &arg);
If I undefined LDL_FIX_GCC_BUG, firmware crashes as self->handler seems to be
nullified. With LDL_FIX_GCC_BUG, firmware never stalls in for(;;) and runs as
expected. Of course, self->handler should be equal to app_handler.
If I replace self->handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, &arg) by
app_handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, &arg), even if I delete code
between #if and #endif, firmware runs also as expected.
Thus, I have checked assembly output.
good_2.S : (https://hilbert.systella.fr/public/good_2.S)
a318: f6 01 movw r30, r12
...
a33c: e3 50 subi r30, 0x03 ; 3
a33e: ff 4f sbci r31, 0xFF ; 255
a340: 01 90 ld r0, Z+
a342: f0 81 ld r31, Z
a344: e0 2d mov r30, r0
This loads Z with R13:R12, and then later offsets it by -0xFF03 to
obtain the address of self->handler, which is then used by the icall
instruction.
bad.S : (https://hilbert.systella.fr/public/bad.S)
a31c: f6 01 movw r30, r12
...
a340: 68 01 movw r12, r16
a342: ff e4 ldi r31, 0x4F ; 79
a344: cf 1a sub r12, r31
a346: fe ef ldi r31, 0xFE ; 254
a348: df 0a sbc r13, r31
a34a: e3 50 subi r30, 0x03 ; 3
a34c: ff 4f sbci r31, 0xFF ; 255
a34e: 01 90 ld r0, Z+
a350: f0 81 ld r31, Z
a352: e0 2d mov r30, r0
Note the clobbering of R31:R30 with immediate values *before* the offsetting is
done. I think this is a codegen bug - the compiler should have either picked a
different set of regs to subtract R13:R12 from, or should have restored Z with
a movw r30, r12 before 0xa34a.
Regards,
JN
More information about the Gcc-bugs
mailing list