When I use cortex-debug in vscode or using ozone (segger.com) I noticed that when single stepping it is showing the incorrect source file. The binary generated is correct but the symbol table reference to source file is incorrect and thus single stepping shows the incorrect code. I found if I revert back to 10.3.1-2.2.1 of the gcc toolchain everything works. Was their a change in the toolchain post 10.3.1 which causes this problem? Testing with 13.3.1-1.1.1 I found that if I did objdump -dlr of my elf file, the disassembly listing does show the correct source, however when running with gdb it did not show the correct source file reference to the disassembly. Note I am running code on a cortex-M0+ if it matters.
Thanks
Trampas
I have found that the `objdump -dlr` produces different listing file formats. Not that this is a cortex-m0 as such address 0x00000 is the SP, so I am not sure what is going on with the listing from 11.3.1 and having "getStackSize()" function in with exception table? Maybe it is multi-threading printing gone wrong?
Also nothing in the i2c_master.cpp is called, as such all references to code in the file should be removed.
10.3.1```build/debug/lora.elf: file format elf32-littlearm
Disassembly of section .text:
00000000 <exception_table>:_sfixed(): 0: ff 7f 00 20 45 04 00 00 0d 05 00 00 4d 05 00 00 ... E.......M... ... 2c: 0d 05 00 00 00 00 00 00 00 00 00 00 0d 05 00 00 ................ 3c: 55 08 00 00 0d 05 00 00 75 0b 00 00 09 06 00 00 U.......u....... 4c: 0d 05 00 00 0d 05 00 00 0d 05 00 00 0d 05 00 00 ................ 5c: 0d 05 00 00 29 07 00 00 4d 07 00 00 71 07 00 00 ....)...M...q... 6c: 95 07 00 00 b9 07 00 00 dd 07 00 00 0d 05 00 00 ................ 7c: 0d 05 00 00 0d 05 00 00 79 09 00 00 b9 09 00 00 ........y....... 8c: f9 09 00 00 39 0a 00 00 79 0a 00 00 0d 05 00 00 ....9...y....... 9c: 0d 05 00 00 0d 05 00 00 0d 05 00 00 0d 05 00 00 ................ ac: 0d 05 00 00 00 00 00 00 ........
000000b4 <__do_global_dtors_aux>:__do_global_dtors_aux(): b4: b510 push {r4, lr} b6: 4c06 ldr r4, [pc, #24] ; (d0 <__do_global_dtors_aux+0x1c>) b8: 7823 ldrb r3, [r4, #0] ba: 2b00 cmp r3, #0 ``` 11.2.1```d:\Projects\SECA\LoRa\firmware\build\debug\lora.elf: file format elf32-littlearm
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 ].......Note that the startup_wlr089.c:254 is the getStackSize(): function:
```10.3.1_lst.txt11.2.1_lst.txtI have also included the elf files if needed: elf.zip
This appears to be an issue as to how the functions that are removed using
GCC-11 marked the change to dwarf-5. I wonder if that is why the behavior changed at that point. Perhaps you could try adding
-gdwarf-4
to use the old format.
Please let us know if that helps, it might help us with tracking down a better solution.
I actually tried it. Apparently this problem might have existed in GCC for over 11 years... I submitted a bug to the Binutils for GCC and they confirmed the bug and noted a bug from 11 years ago. I do not think it will ever be fixed because there is such a small audience this causes issues for.
I think fundamentally the problem is that GCC puts all debug data into one section in the object file, even when separate function sections are generated. This means that the linker is unable to discard those parts of the debug data that refer to discarded code. The linker therefore has to try to point that to something that won't be relevant in the final image, but I suspect it uses address zero for that (most images don't have code at the start of the address space so that NULL pointers will fault). But of course, in your situation address zero is where your reset data is held.
I'm not entirely sure why older versions of GCC were exhibiting slightly different behaviour though. It might have been luck, or it might be related to the switch to Dwarf-5 that just exposes the problem slightly differently; but I agree that this is unlikely to be fixable in a robust manner (re-engineering GCC's debug generator code would be a phenomenal amount of work for very little real gain).