[Issue 3214] New: Incorrect DWARF line number debugging information on Linux

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3214

           Summary: Incorrect DWARF line number debugging information on
                    Linux
           Product: D
           Version: 1.046
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Keywords: wrong-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody at puremagic.com
        ReportedBy: nfxjfg at gmail.com


Here's an example that shows that dmd obviously/probably generates incorrect
DWARF line number debugging information under Linux. The example consists of
several modules, and I don't know if it's further reducible, or where the
problem actually is. (I'm happy that's it's reproducible at all.)

a.d >>>
module a;

import b;

void main(char[][] args) {
    throw new Exception("huh");
}
<<<

b.d >>>
module b;

import c;

void foo1() {
}
<<<

c.d >>>
module c;

class Foo2 : Exception {
    this() {
        super("huh");
    }
}
<<<

Compile exactly like this:
  dmd -c a.d b.d c.d -od. -g
  dmd  a.o b.o c.o  -ofa -g

Now look what is wrong and check if the symbol "_D1c4Foo25_ctorMFZC1c4Foo2" is
correct:

1. Get address:
  nm a|grep _D1c4Foo25_ctorMFZC1c4Foo2 |cut -f2 -d: | cut -f1 -d' '
(outputs something like "08049b64")
2. Resolve the address:
  addr2line -e a 0x08049b64

This outputs "/tmp/test/xx/b.d:5", although the symbol is in c.d. Somehow, the
address is incorrectly resolved, which suggests that the compiler might
generate incorrect debugging information.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------