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