bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/32506] New: removed functions showing up in objdump listin


From: trampas at gmail dot com
Subject: [Bug binutils/32506] New: removed functions showing up in objdump listing and gdb
Date: Sat, 28 Dec 2024 01:16:40 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=32506

            Bug ID: 32506
           Summary: removed functions showing up in objdump listing and
                    gdb
           Product: binutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: trampas at gmail dot com
  Target Milestone: ---

Created attachment 15862
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15862&action=edit
sample makefile project demonstrating the issue

I am building code for a cortex-m0 using arm-none-eabi. My project has lots of
functions removed using the -ffunction-sections -fdata-sections
-Wl,--gc-sections options. When I started stepping into my code I found that
gdb was showing the wrong source, specifically it will show code was from
functions that were removed (never called).

I did some testing and noticed that if I use GCC 11 or newer (including latest
14.2Rel1) this happens but GCC 10 appears to work correctly. I also found that
if I use objdump -dlr to dump the problematic elf files it shows the issues
like below:

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():

All the file references above are bogus, for example getStackSize() is not in
the binary, and definitely not the source for the exception vector table!    

What I can roughly determine is that GCC 11 and later appears to be placing all
the code that was removed using -ffunction-sections -fdata-sections
-Wl,--gc-sections at address 0x0000. This appears to cause gdb/objdump to
incorrectly think source code near address 0x0000 is from functions that have
been removed.

I even tried to use readelf to dump all the symbols `readelf -a` and when doing
this the getStackSize symbol is not in the output.

Replicating bug:
The project in attachment is a makefile project. 

The readme.md has instructions on how to build in windows, by installing xpack
utility. 

If you build in linux then just edit the path in makefile to the
arm-none-eabi-gcc compiler and path to build tools you want use and then issue
`make debug`.

The build/debug/lora.lst should show the error when built with
arm-none-eabi-gcc 11.2.1-1.1.1 or greater:

0000016c <configure_clocks>:
D:\Projects\SECA\LoRa\firmware/src/drivers/sercom/sercom.cpp:102
 16c:   b500            push    {lr}
 16e:   4b98            ldr     r3, [pc, #608]  ; (3d0 <HEAP_SIZE+0x1d0>)
 170:   2280            movs    r2, #128        ; 0x80
D:\Projects\SECA\LoRa\firmware/src/drivers/sercom/sercom.cpp:106
 172:   0052            lsls    r2, r2, #1
 174:   609a            str     r2, [r3, #8]
D:\Projects\SECA\LoRa\firmware/src/drivers/sercom/sercom.cpp:107
 176:   4b97            ldr     r3, [pc, #604]  ; (3d4 <HEAP_SIZE+0x1d4>)
 178:   3afd            subs    r2, #253        ; 0xfd

Specifically the configure_clocks() function does not exist in the sercom.cpp
file. 

When built with GCC 10 tools the results are as expected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]