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 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).