Thanks Richard!
I have requested an account with the gcc bugzilla system.
Trampas
On Fri, Dec 27, 2024 at 5:05 AM Richard Biener <richard.guent...@gmail.com>
wrote:
>
>
> > 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
>
