View mode: basic / threaded / horizontal-split · Log in · Help
April 02, 2007
DMD on Linux?
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
April 02, 2007
Re: DMD on Linux?
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/
April 02, 2007
Re: DMD on Linux?
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
April 02, 2007
Re: DMD on Linux?
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
April 03, 2007
Re: DMD on Linux?
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/
April 03, 2007
Re: DMD on Linux?
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.
>
April 03, 2007
Re: DMD on Linux?
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!
Top | Discussion index | About this forum | D home