> Am 27.12.2024 um 02:50 schrieb Trampas Stern via Gcc <gcc@gcc.gnu.org>:
>
> I am doing embedded development on an arm cortex-m processor using
> arm-none-eabi-gcc. I have run into a bug where GDB is showing that the
> code executing is code from a function that is not used. The code is
> removed as it is not called, and hence -ffunction-sections -fdata-sections
> -Wl,--gc-sections has removed it.
> The issue appears that sometime around January 2022 with introduction of
> GCC 11 the elf file output changed to including these function symbols and
> then mapping them to address zero.
>
> The result is that there are several function symbols mapped to address 0
> and then gdb seems to randomly pick which code it thinks is running. For
> example when running a loop like:
> int i=100;
> while (i>0) {
> i--;
> }
> GDB might decide the i--; is some other random line in a seemingly random
> file/function that is not in the binary image. As such stepping through
> code it will jump between random locations.
>
> I have found that the 10.3.1 toolchain does not have this issue, but every
> one I have tried after and including 11.2.1 has this issue. I seem to
> recall around GCC 11 there was a change for -flto and was wondering if this
> created this issue?
>
> I have noticed that when I build elf files with both versions of code the
> failing version will have errors in the objdump -dlr output. For example:
>
> Disassembly of section .text:
>
> 00000000 <exception_table>:
> getStackSize():
> D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:244
> 0: ff 7f 00 20 95 04 00 00 5d 05 00 00 9d 05 00 00 ... ....].......
> ...
> getStackUsed():
> D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:254
> 2c: 5d 05 00 00 00 00 00 00 00 00 00 00 5d 05 00 00 ]...........]...
> D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:257
> 3c: c5 08 00 00 5d 05 00 00 f9 0b 00 00 65 06 00 00 ....].......e...
> D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:250
> 4c: 5d 05 00 00 5d 05 00 00 5d 05 00 00 5d 05 00 00 ]...]...]...]...
> D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:267
> 5c: 5d 05 00 00 99 07 00 00 bd 07 00 00 e1 07 00 00 ]...............
> 6c: 05 08 00 00 29 08 00 00 4d 08 00 00 5d 05 00 00 ....)...M...]...
> _ZN10I2C_MASTER4syncEv():
> D:\Projects\SECA\LoRa\firmware/src/drivers/i2c_master/i2c_master.cpp:90
> 7c: 5d 05 00 00 5d 05 00 00 e9 09 00 00 29 0a 00 00 ]...].......)...
> _ZN10I2C_MASTER18setCommandBitsWireEh():
> D:\Projects\SECA\LoRa\firmware/src/drivers/i2c_master/i2c_master.cpp:90
>
> In the above the objdump is confused and mixing the getStackSize() function
> (is not in binary) with the exception vector table. As you can see in the
> listing above the objdump seems to change which function it is guessing
> should be used changing to _ZN10I2C_MASTER4syncEv(): and then
> _ZN10I2C_MASTER18setCommandBitsWireEh():
>
> I found this continues into real function and yields weird results when
> stepping through code in a debugger (gdb).
>
> I have tried -flto and everything else to remove these unused symbols from
> the elf file and nothing seems to work.
>
> Is this a bug in the toolchain? Is there a possible work around?
I suggest you file a bugzilla Report with a reproducer.
Richard
> Thanks
> Trampas
