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?
> > 
> 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.
> 

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
>> 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 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.
> 
It may be related to incorrect line info from DMD, I will investigate it.

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

Thanks!