https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118221
Bug ID: 118221
Summary: gdb and objdump referencing functions that do no exist
in binary
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: trampas at gmail dot com
Target Milestone: ---
Created attachment 59990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59990&action=edit
Elf files from 10.3 and 11.2
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 (cortex-debug and segger
ozone), the code was going into driver functions that were never called and not
in bianry. 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.
To replicate the issue take a version of objdump, so far any
arm-none-eabi-objdump version I tested will work.
Then issue the following two commands on the elf files:
objdump -dlr lora_10.3.1-2.2.1.elf >10.3.1.lst
objdump -dlr lora_11.2.1-1.1.1.elf >11.2.1.lst
Now look at the lst output and the file/line references.
I have been assuming that gdb is using the same tools as objdump under the
cover to convert the elf file back to original source code reference.
