Hello,
I've notice that gdb was improperly displaying source lines with
disassembled code.
I looked at the assembly to check what is inlined and what not
and the difference between the use of is and == in the machine
code.
I then tested with objdump with a simple program and saw the same
problem.
Here is the source code displayed with $ nl -da app.d and adding
a white space in empty lines because it doesn't count empty lines
even with option -ba.
1 import std.stdio;
2
3 void main()
4 {
5 int a = 10;
6
7 a += 3;
8
9 ++a;
10
11 writefln("Value: %d", a);
12
13 writeln("Helloworld!");
14
15 }
This is the output of $ objdump --dwarf=decodedline app.o | less
CU: app.d:
Nom fichier Num ligne Adresse début
./app.d:[++]
app.d 3
0
app.d 5
0x8
app.d 7
0xf
app.d 9
0x13
app.d 11
0x16
app.d 9
0x20
app.d 13
0x28
app.d 15
0x3c
...
This is the output I get with $ objdump -d -S app > app.txt for
the function _Dmain.
000000000043aae8 <_Dmain>:
import std.stdio;
void main()
43aae8: 55 push %rbp
43aae9: 48 8b ec mov %rsp,%rbp
43aaec: 48 83 ec 10 sub $0x10,%rsp
{
int a = 10;
43aaf0: c7 45 f8 0a 00 00 00 movl $0xa,-0x8(%rbp)
a += 3;
43aaf7: 83 45 f8 03 addl $0x3,-0x8(%rbp)
++a;
43aafb: ff 45 f8 incl -0x8(%rbp)
writefln("Value: %d", a);
43aafe: ba 60 e5 46 00 mov $0x46e560,%edx
43ab03: be 09 00 00 00 mov $0x9,%esi
{
int a = 10;
a += 3;
++a;
43ab08: 8b 7d f8 mov -0x8(%rbp),%edi
43ab0b: e8 18 00 00 00 callq 43ab28
<_D3std5stdio19__T8writeflnTAyaTiZ8writeflnFNfAyaiZv>
writefln("Value: %d", a);
writeln("Helloworld!");
43ab10: ba 6a e5 46 00 mov $0x46e56a,%edx
43ab15: bf 0b 00 00 00 mov $0xb,%edi
43ab1a: 48 89 d6 mov %rdx,%rsi
43ab1d: e8 e6 9b 00 00 callq 444708
<_D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv>
43ab22: 31 c0 xor %eax,%eax
}
43ab24: c9 leaveq
43ab25: c3 retq
43ab26: 66 90 xchg %ax,%ax
000000000043ab28
<_D3std5stdio19__T8writeflnTAyaTiZ8writeflnFNfAyaiZv>:
}
As you can see the source lines don't match the assembly after
++a. I have the impression the error is in the debug line number
table. The jump from 11 back to 9 look suspect. This is also
where the source line display with disassembled code start to get
bogus.
I get a similar output with gdb. I can't determine if the problem
is in libdwarf or in the .debug info in the file because it's
beyond my competence.
Is this normal ? I guess it confuses debuggers and render them
useless.
