www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Problem with .debug info in program

reply chmike <christophe meessen.net> writes:
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.
May 24 2016
next sibling parent reply chmike <christophe meessen.net> writes:
Here you have the object lines from app with the addresses.

./app.d:[++]
app.d                                      3            0x43aae8
app.d                                      5            0x43aaf0
app.d                                      7            0x43aaf7
app.d                                      9            0x43aafb
app.d                                     11            0x43aafe
app.d                                      9            0x43ab08
app.d                                     13            0x43ab10
app.d                                     15            0x43ab24
May 24 2016
parent reply chmike <christophe meessen.net> writes:
After closer examination it seam that the second line with 9 is a 
bogus insertion. Removing it should fix the code line table.

 app.d                                      9            0x43aafb
 app.d                                     11            0x43aafe
 app.d                                      9            
 0x43ab08  <= to remove
 app.d                                     13            0x43ab10
 app.d                                     15            0x43ab24
May 24 2016
parent Basile B. <b2.temp gmx.com> writes:
On Tuesday, 24 May 2016 at 13:17:22 UTC, chmike wrote:
 After closer examination it seam that the second line with 9 is 
 a bogus insertion. Removing it should fix the code line table.

 app.d                                      9            
 0x43aafb
 app.d                                     11            
 0x43aafe
 app.d                                      9            
 0x43ab08  <= to remove
 app.d                                     13            
 0x43ab10
 app.d                                     15            
 0x43ab24
Direction le bug tracker: https://issues.dlang.org/
May 24 2016
prev sibling parent Kagamin <spam here.lot> writes:
Probably normal, see this discussion: 
https://forum.dlang.org/post/mailman.400.1389749305.15871.digitalmars-d puremagic.com
Anyway dmd is not known to have a quality backend, try ldc or gdc.
May 24 2016