digitalmars.D.learn - Problem with .debug info in program
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 | lessCU: 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
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
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
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.Direction le bug tracker: https://issues.dlang.org/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
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