GDB debugging showing wrong code

[Trampas Stern]

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.guenther@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
>