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.

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

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

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/

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.