• Cristian Vlasceanu <cristian zero-bugs.com> Apr 02 2007
• John Demme <me teqdruid.com> Apr 02 2007
• Cristian Vlasceanu <cristian zerobugs.org> Apr 02 2007
• Cristian Vlasceanu <cristian zerobugs.org> Apr 02 2007
• John Demme <me teqdruid.com> Apr 02 2007
• Cristian Vlasceanu <cristian zero-bugs.com> Apr 02 2007
• Cristian Vlasceanu <cristian zerobugs.org> Apr 03 2007

Hello,

Has anyone tried debugging a DMD-compiled program on Linux recently?

I am seeing incorrect source file paths in Zero and verified with 
dwarfdump and readelf that the DWARF info generated by DMD is wrong. The 
  funny thing is that this used to work in 0.174 or so.

Anyone having the same experience or am I seeing things?

I have already email Walter about this issue and as he is slow as usual 
in addressing Linux back-end issues I  was thinking about hacking Zero 
so that if it cannot locate the source (it is just the path that's 
wrong, the filename is okay) then go recursively search for it in the 
parent dir tree of the binary.

Of course it assumes that one builds their executables in the source dir 
tree.

Thoughts?

  Cristian Vlasceanu
http://www.zerobugs.org

Cristian Vlasceanu wrote:

 Hello,
 
 Has anyone tried debugging a DMD-compiled program on Linux recently?
 
 I am seeing incorrect source file paths in Zero and verified with
 dwarfdump and readelf that the DWARF info generated by DMD is wrong. The
   funny thing is that this used to work in 0.174 or so.
 
 Anyone having the same experience or am I seeing things?
 
 I have already email Walter about this issue and as he is slow as usual
 in addressing Linux back-end issues I  was thinking about hacking Zero
 so that if it cannot locate the source (it is just the path that's
 wrong, the filename is okay) then go recursively search for it in the
 parent dir tree of the binary.
 
 Of course it assumes that one builds their executables in the source dir
 tree.
 
 Thoughts?
 
   Cristian Vlasceanu
 http://www.zerobugs.org


What if there are multiple files by the same name in different directories? 
Also, I frequently have the programs I'm debugging in a separate directory
from the source since I'll be working on a library and the test code is in,
say, a unittest directory or examples directory-- separate from the library
code.

I was debugging a program built with DMD 1.010 the other day and Zero
appeared to be finding the source files fine, though.  I'm using Zero:
Zero (v1.5.41 Jan 31 2007 12:40:08)
The Linux Application Debugger (Linux 2.6.19-gentoo-r2/x86_64) root capetown

That version of Zero had some pretty bad issues with the stack trace on that
particular program, by the way, but I know it's a pretty old version.

-- 
~John Demme
me teqdruid.com
http://www.teqdruid.com/

John Demme Wrote:

 Of course it assumes that one builds their executables in the source dir
 tree.
 
 Thoughts?
 


 Also, I frequently have the programs I'm debugging in a separate directory
 from the source since I'll be working on a library and the test code is in,
 say, a unittest directory or examples directory-- separate from the library
 code.
 


Yes, the hackish workaround that I suggested would not work in these cases.

 I was debugging a program built with DMD 1.010 the other day and Zero
 appeared to be finding the source files fine, though.  I'm using Zero:
 Zero (v1.5.41 Jan 31 2007 12:40:08)
 The Linux Application Debugger (Linux 2.6.19-gentoo-r2/x86_64) root capetown
 
 That version of Zero had some pretty bad issues with the stack trace on that
 particular program, by the way, but I know it's a pretty old version.
 


Could you send me the code, or a boiled-down test case, please?

I was going to update the version that you are using, so maybe I can work out a
fix before updating (or at least diagnose the problem).

Thanks
  Cristian

John Demme Wrote:

 I was debugging a program built with DMD 1.010 the other day and Zero
 appeared to be finding the source files fine, though.  I'm using Zero:
 Zero (v1.5.41 Jan 31 2007 12:40:08)
 The Linux Application Debugger (Linux 2.6.19-gentoo-r2/x86_64) root capetown


Very strange, indeed DMD 1.010 seems to work fine on one Ubuntu x86_64
installation, but it acts up on my Mandriva 2007 and Suse 10.0 systems.

As for the stack trace problems, what is the behavior that you are seeing in
Zero?

Thanks
   Cristian

Cristian Vlasceanu wrote:

 John Demme Wrote:
 
 I was debugging a program built with DMD 1.010 the other day and Zero
 appeared to be finding the source files fine, though.  I'm using Zero:
 Zero (v1.5.41 Jan 31 2007 12:40:08)
 The Linux Application Debugger (Linux 2.6.19-gentoo-r2/x86_64)
 root capetown


 Very strange, indeed DMD 1.010 seems to work fine on one Ubuntu x86_64
 installation, but it acts up on my Mandriva 2007 and Suse 10.0 systems.
 
 As for the stack trace problems, what is the behavior that you are seeing
 in Zero?
 
 Thanks
    Cristian


One of two things:
-The current stack frame is shown correctly (except the symbol name is not
demangled) and the next frame will be 000000000002 (or some other low
number) then ???.  These are the only two stack frames shown
-Also, sometimes the same thing happens, but the second line is a line in
some system library.

Additionally, if I open a file by hand after loading a program, I can't set
a breakpoint in it.  If I step into a function in that file, it opens
another tab with the same file and I'm able to set breakpoints only in that
one.  I'd be nice if there was a dropdown or something with a list of all
the files the program refers to and I can select them to open them.

-- 
~John Demme
me teqdruid.com
http://www.teqdruid.com/

After more research, it appears that the bug that I am seeing is not the 
DMD compiler's fault:

dmd -g -c nested.d
readelf -w nested.o
produces:
[snip]
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
      DW_AT_stmt_list   : 0
      DW_AT_name        : nested.d
      DW_AT_comp_dir    : (indirect string, offset: 0x0): 
/home/cristiv/workspace/d
      DW_AT_producer    : Digital Mars D v1.010
[/snip]

So far we're okay! DW_AT_comp_dir is correct

dmd nested.o
(invokes) gcc nested.o -o nested -m32 -lphobos -lpthread -lm

readelf -w nested
produces:
[snip]
<0><121>: Abbrev Number: 1 (DW_TAG_compile_unit)
      DW_AT_stmt_list   : 0xc7
      DW_AT_name        : nested.d
      DW_AT_comp_dir    : (indirect string, offset: 0x0): short int
      DW_AT_producer    : Digital Mars D v1.010
      DW_AT_language    : 19     (Unknown: 13)
[/snip]

Directory is "short int"??? Obviously the linker screwed it up.

[cristiv orcas:~/workspace/d]$ gcc -v
Using built-in specs.
Target: x86_64-mandriva-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib 
--with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info 
--enable-shared --enable-threads=posix --enable-checking=release 
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java 
--host=x86_64-mandriva-linux-gnu --with-cpu=generic --with-system-zlib 
--enable-long-long --enable-__cxa_atexit --enable-clocale=gnu 
--disable-libunwind-exceptions --enable-java-awt=gtk 
--with-java-home=/usr/lib/jvm/java- 1.4.2-gcj-1.4.2.0/jre 
--enable-gtk-cairo --enable-ssp --disable-libssp
Thread model: posix
gcc version 4.1.1 20060724 (prerelease) (4.1.1-3mdk)


John Demme wrote:
 Cristian Vlasceanu wrote:
 
 John Demme Wrote:

 I was debugging a program built with DMD 1.010 the other day and Zero
 appeared to be finding the source files fine, though.  I'm using Zero:
 Zero (v1.5.41 Jan 31 2007 12:40:08)
 The Linux Application Debugger (Linux 2.6.19-gentoo-r2/x86_64)
 root capetown


 installation, but it acts up on my Mandriva 2007 and Suse 10.0 systems.

 As for the stack trace problems, what is the behavior that you are seeing
 in Zero?

 Thanks
    Cristian


 One of two things:
 -The current stack frame is shown correctly (except the symbol name is not
 demangled) and the next frame will be 000000000002 (or some other low
 number) then ???.  These are the only two stack frames shown
 -Also, sometimes the same thing happens, but the second line is a line in
 some system library.
 
 Additionally, if I open a file by hand after loading a program, I can't set
 a breakpoint in it.  If I step into a function in that file, it opens
 another tab with the same file and I'm able to set breakpoints only in that
 one.  I'd be nice if there was a dropdown or something with a list of all
 the files the program refers to and I can select them to open them.
 

John Demme Wrote:


 One of two things:
 -The current stack frame is shown correctly (except the symbol name is not
 demangled) and the next frame will be 000000000002 (or some other low
 number) then ???.  These are the only two stack frames shown
 -Also, sometimes the same thing happens, but the second line is a line in
 some system library.
 


I am about to fix the demangling problem.

 Additionally, if I open a file by hand after loading a program, I can't set
 a breakpoint in it.  If I step into a function in that file, it opens
 another tab with the same file and I'm able to set breakpoints only in that
 one.  I'd be nice if there was a dropdown or something with a list of all
 the files the program refers to and I can select them to open them.
 



And yes, the dropdown is a good idea, will look into it.

Thanks!