gdb source reference verses objdump

[Trampas Stern]

I am working on a cortex-m embedded project.  I typically start by copying
over all my drivers into my src/drivers, then libraries in src/libraries.
I will then add a simple main() file something like:
int main()
{
  int i=0;
  i=i+1;
 return 0;
}

Then I set up the build environment and set through the start up code, aka
reset vector and configuring clocks.

I noticed that stepping through the code with gdb, the code was going into
driver functions that were never called.  I do enable the compile time
options of -ffunction-sections -fdata-sections -Wl,--gc-sections such that
the driver code is not in the binary/elf output.  As such I was confused as
to why the code was going off into weird states.

I finally did an objdump -dlr out.elf >out.lst, there I noticed some weird
things.  First off the exception vector table looked to be overlapped with
code.

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
  8c: 69 0a 00 00 a9 0a 00 00 e9 0a 00 00 5d 05 00 00     i...........]...
_sfixed():
D:\Projects\SECA\LoRa\firmware/src/drivers/i2c_master/i2c_master.cpp:91
  9c: 5d 05 00 00 5d 05 00 00 5d 05 00 00 5d 05 00 00     ]...]...]...]...
_ZN10I2C_MASTER9read_byteEPh():
D:\Projects\SECA\LoRa\firmware/src/drivers/i2c_master/i2c_master.cpp:93
  ac: 5d 05 00 00 00 00 00 00                             ].......

Finally after days and days of debugging I figured out that GCC 10 did not
have this problem and it only occurs in GCC 11 and newer.

Basically from what I can figure out in gcc 11 and later the elf file is
keeping all the symbols for functions that were removed. As a result it
appears that gdb and objdump tries to place these functions at address
0x000.   When gdb does this and you step through code it is almost random
as to which function and line it decides to show as you step through the
code.   This obviously causes a nightmare to the poor developer trying to
figure out what is going on.

Can someone confirm that this is indeed a bug in gdb/objdump?

I am also amazed that no one has seen this behavior in ~3 years since GCC
11 release, as such I am questioning my sanity as to this being a real bug
and not something on my end, like a compiler/linker option.

Thanks
Trampas