DMD on Linux?

Discussion:

DMD on Linux?

Cristian Vlasceanu

2007-04-02 16:48:15 UTC

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

John Demme

2007-04-02 17:08:03 UTC

Permalink

Post by Cristian Vlasceanu
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 at 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 at teqdruid.com
http://www.teqdruid.com/

Cristian Vlasceanu

2007-04-02 18:23:43 UTC

Permalink

Post by John Demme

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

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

Post by John Demme
I was debugging a program built with DMD 1.010 the other day and Zero
Zero (v1.5.41 Jan 31 2007 12:40:08)
The Linux Application Debugger (Linux 2.6.19-gentoo-r2/x86_64) root at 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

Cristian Vlasceanu

2007-04-02 23:04:33 UTC

Permalink

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

John Demme

2007-04-03 02:31:07 UTC

Permalink

Post by Cristian Vlasceanu

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 at teqdruid.com
http://www.teqdruid.com/

Cristian Vlasceanu

2007-04-03 05:23:27 UTC

Permalink

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 at 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)

Post by John Demme

Post by Cristian Vlasceanu

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

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

Cristian Vlasceanu

2007-04-03 22:06:10 UTC

Permalink

Post by John Demme
-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.

Post by John Demme
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!