Showing source file incorrect when using gdb #39

trampas · 2024-12-26T17:44:14Z

trampas
Dec 26, 2024

I found that when using cortex-debug in vscode or using ozone (segger.com) when I single step through code or view the disassembly the source code reference is incorrect for any version of gcc after 10.3.1-2.2.1.

If I do an objdump -dlr of the elf file, then the disassembly and source code is shown correctly, but when accessing through the gdb interface on cortex-debug or ozone the source file is shown incorrect. The assembly (binary) code is correct but the link back to source code (symbol table?) appears to be wrong.

Does anyone know if there a change in gcc that created this issue?
Has anyone else seen this issue?

ilg-ul · 2024-12-26T18:04:47Z

ilg-ul
Dec 26, 2024
Maintainer

I don't know, but I'm not surprised.

Debuggers usually ask gdb to do the disassembly, at least this is how Eclipse does.

I suggest you test directly with gdb in a terminal. If the disassembly is incorrect, then the issue is in gdb.

0 replies

trampas · 2024-12-26T18:40:20Z

trampas
Dec 26, 2024
Author

In vscode for disassembly view for 11.2.1-1.1.1 we see:

As you see 0x019c is the 'add r7,sp #0/ but the source reference above it is incorrect.
The gdb 'disassemble /s' shows the correct source reference.

As such I am not sure what cortex-debug and vscode are doing. I am have not used gdb on the command line much, as such I am unsure what vscode/cortex-debug) is doing to get the source file references?

1 reply

ilg-ul Dec 26, 2024
Maintainer

Aha. So the disassembly itself is correct, and only the reference to the source code is wrong.

In this case I would say that either the debug information in your sources is not right, or VS Code/Ozone have issues.

For VS Code I'm not surprised, but Ozone should be more trustworthy.

Therefore my first choice would be to try different -g options, perhaps there is one that is better understood by VS Code.

trampas · 2024-12-26T19:16:50Z

trampas
Dec 26, 2024
Author

I tried -g and -g3 with no changes in results. I ran the cortex-debug with gdb showDevDebugOutput set to raw and logged for 11.2.1 and 10.3.1

11.2.1.txt
10.3.1.txt

I noticed in 11.2.1:

17^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x000001ca",func="configure_clocks",file="src/CMSIS/wlr089/source/gcc/startup_wlr089.c",fullname="D:\\Projects\\SECA\\LoRa\\firmware\\src\\CMSIS\\wlr089\\source\\gcc\\startup_wlr089.c",line="322",thread-groups=["i1"],times="0",original-location="d:\\Projects\\SECA\\LoRa\\firmware\\src\\CMSIS\\wlr089\\source\\gcc\\startup_wlr089.c:322"}
18-break-insert *0x000000bc
-> 18^done,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x000000bc",func="I2C_MASTER::read(unsigned char, bool, unsigned char*, unsigned int)",file="src/drivers/i2c_master/i2c_master.cpp",fullname="D:\\Projects\\SECA\\LoRa\\firmware\\src\\drivers\\i2c_master\\i2c_master.cpp",line="93",thread-groups=["i1"],times="0",original-location="*0x000000bc"}

Note the i2c_master.cpp file has no functions called in this file, so it is stripped from binary.

While in 10.3.1:

17-break-insert "d:\\Projects\\SECA\\LoRa\\firmware\\src\\CMSIS\\wlr089\\source\\gcc\\startup_wlr089.c:322"
-> 17^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0000017a",func="configure_clocks",file="src/CMSIS/wlr089/source/gcc/startup_wlr089.c",fullname="D:\\Projects\\SECA\\LoRa\\firmware\\src\\CMSIS\\wlr089\\source\\gcc\\startup_wlr089.c",line="322",thread-groups=["i1"],times="0",original-location="d:\\Projects\\SECA\\LoRa\\firmware\\src\\CMSIS\\wlr089\\source\\gcc\\startup_wlr089.c:322"}
18-break-insert *0x000000bc
-> 18^done,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="0x000000bc",at="<__do_global_dtors_aux+8>",thread-groups=["i1"],times="0",original-location="*0x000000bc"}
Debug-10: Enqueuing {"command":"disassemble","arguments":{"memoryReference":"0x0000010c","offset":0,"instructionOffset":0,"instructionCount":1,"resolveSymbols":true},"type":"request","seq":10}

I will research some more and see what I find.

1 reply

ilg-ul Dec 26, 2024
Maintainer

These are old releases, I suggest you try with the latest release.

trampas · 2024-12-26T19:33:30Z

trampas
Dec 26, 2024
Author

I first started with the latest release and had the issue, I started moving down major releases until issue went away.

I have found that the objdump -dlr produces different listing files.

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


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

11.2.1_lst.txt
10.3.1_lst.txt

3 replies

ilg-ul Dec 26, 2024
Maintainer

Could you also try with the official Arm release? If that one works and the xPack release does not, I have to identify what's wrong with my build.

trampas Dec 26, 2024
Author

I have tried it with about 3 versions of the tools post 10.3, including the latest. As such I doubt you got 3-4 versions copied wrong.

So looking at the listing file, I am betting that someone added multi-threading to the objdump. If you notice the exception_table output you will see the output is intermixed with the getStackSize(): function.

My guess is they have two threads printing to the file at the same time and corrupting the output.

ilg-ul Dec 26, 2024
Maintainer

I doubt you got 3-4 versions copied wrong.

well, I use exactly the same sources as Arm, but I cannot copy their build scripts, since they use a different environment.

therefore I have my own scripts, which I manually update from time to time with Arm scripts updates, so it is perfectly possible that at a certain moment I did some changes that introduced this behaviour, which was repeated in every release since then.

so, if the problem does not occur with Arm releases, the problem is in my scripts.

trampas · 2024-12-26T20:52:20Z

trampas
Dec 26, 2024
Author

Version 14.1 rel1 of the arm GNU toolchain has same issue. I found it appears to be a difference in the elf file generated, as if I do objdump with newer objdump and older elf it works correctly.

4 replies

ilg-ul Dec 26, 2024
Maintainer

Version 14.1 rel1 of the arm GNU toolchain has same issue.

You mean VS Code messes the output? And you suggest that the problem is upstream?

if I do objdump with newer objdump and older elf it works correctly.

So the objdump in 14.4 rel1 is ok but VS Code is still messing the output? Weird...

BTW, I'll make a new release with 14.4 in a few days, as soon as I finish with the project web.

trampas Dec 26, 2024
Author

I am no expert on the elf file format, well not yet...... However I have enclosed the two elf files here if anyone is.

I basically do an objdump -dlr xxxx.elf > out.lst to recreate the errors.
elf.zip

trampas Dec 26, 2024
Author

The best I can tell is the problem is upstream, maybe in the GCC repro, or maybe with newer versions of compiler I need different link options to generate elf file correctly.

Basically take whatever version of objdump you have and run the following:

arm-non-eabi-objdump -dlr lora_10.3.1-2.2.1.elf > v10.txt
arm-non-eabi-objdump -dlr lora_11.2.1-1.1.1.elf > v11.txt

Then inspect the two output files. What I see is at the top of the v11.txt I get the following:

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

Where in the v10.txt I get what it should look like which is:

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

The references to getStackSize(): D:\Projects\SECA\LoRa\firmware/src/CMSIS/wlr089/source/gcc/startup_wlr089.c:244

Should not be in the output

What appears to be happening is the elf file has some errors and causing objdump to add in the extra lines. These extra lines are getting parsed by the cortex-debug extension in vscode, as well as ozone, and causing it to get source file references incorrect.

trampas Dec 26, 2024
Author

I am not sure if cortex-debug use the objdump output directly or maybe uses gdb output, which most likely under the covers uses the same code to parse the PC address to line in code. Either way the cortex-debug gets really confused when I use anything newer than 10.3.1.
Now given that 10.3.1 is 3 years old. I would be shocked if I am finding a bug no one else did. As such most likely I am doing something wrong in my Makefile. That is most likely need a new linker option that was added post 10.3.1 to make everything happy.

Makefile.txt

trampas · 2024-12-26T23:40:57Z

trampas
Dec 26, 2024
Author

I think what is happening is that the unused functions still have their symbol in the elf file. As such the tools are placing these functions at address zero. I am not sure how the gdb/objdump picks which symbol (source file/function) to assign but it picks one, and often the wrong one.
I figure most people never see this as their programs might not start at address 0 or they have few unused functions and then debug code far away from address zero.
I think this change in GCC was added in GCC 11 which I suspect is when they added -flto option...

1 reply

ilg-ul Dec 27, 2024
Maintainer

unused functions still have their symbol in the elf file

it is possible.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Showing source file incorrect when using gdb #39

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 6 comments 10 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Showing source file incorrect when using gdb #39

trampas Dec 26, 2024

Replies: 6 comments · 10 replies

ilg-ul Dec 26, 2024 Maintainer

trampas Dec 26, 2024 Author

ilg-ul Dec 26, 2024 Maintainer

trampas Dec 26, 2024 Author

ilg-ul Dec 26, 2024 Maintainer

trampas Dec 26, 2024 Author

ilg-ul Dec 26, 2024 Maintainer

trampas Dec 26, 2024 Author

ilg-ul Dec 26, 2024 Maintainer

trampas Dec 26, 2024 Author

ilg-ul Dec 26, 2024 Maintainer

trampas Dec 26, 2024 Author

trampas Dec 26, 2024 Author

trampas Dec 26, 2024 Author

trampas Dec 26, 2024 Author

ilg-ul Dec 27, 2024 Maintainer

trampas
Dec 26, 2024

Replies: 6 comments 10 replies

ilg-ul
Dec 26, 2024
Maintainer

trampas
Dec 26, 2024
Author

ilg-ul Dec 26, 2024
Maintainer

trampas
Dec 26, 2024
Author

ilg-ul Dec 26, 2024
Maintainer

trampas
Dec 26, 2024
Author

ilg-ul Dec 26, 2024
Maintainer

trampas Dec 26, 2024
Author

ilg-ul Dec 26, 2024
Maintainer

trampas
Dec 26, 2024
Author

ilg-ul Dec 26, 2024
Maintainer

trampas Dec 26, 2024
Author

trampas Dec 26, 2024
Author

trampas Dec 26, 2024
Author

trampas
Dec 26, 2024
Author

ilg-ul Dec 27, 2024
Maintainer