www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Debugging LDC executables

reply Timo Gransch <timo.gransch web.de> writes:
Hi everyone!

I installed LDC on my Ubuntu 9.04/x86-64 system from the Launchpad Apt
repository. So far it works great, but debugging is strange.

I compile using

ldc -g -debug test.d

which should add symbolic debugger information to the executable, but
when I run 'list' in gdb (original Debian/Ubuntu version as well as a
self-compiled version with the current D patches) subsequently, I won't
be shown the compiled source code, but obviously code from a lower
level, which looks like

159	 */
160	int main(char[][] args);
161	
162	/***********************************
163	 * Substitutes for the C main() function.
164	 * It's purpose is to wrap the call to the D main()
165	 * function and catch any unhandled exceptions.
166	 */
167	
168	extern (C) int main(int argc, char **argv, char** env)
(gdb)
169	{
(...)

Is there any way to fix this? Do I need other parameters to compile?

Best regards,
Timo
May 25 2009
next sibling parent reply MIURA Masahiro <echochamber gmail.com> writes:
Hi, I'm also looking forward to using debugger on Linux!

Timo Gransch wrote:

 I compile using
 
 ldc -g -debug test.d


Earlier this month I tried to debug LDC-compiled programs with llvm-db,
the LLVM debugger, on Ubuntu.  It seems to be immature, unfortunately:

% ldc -g ./resauth.d
% ./resauth
<<works correctly>>
% llvm-db ./resauth
NOTE: llvm-db is known useless right now.
llvm-db: The LLVM source-level debugger
Loading program... Error: Could not find program './resauth'!
(llvm-db) %

The llvm-db is installed with "sudo apt-get install llvm".
Perhaps a newer llvm-db is usable, I haven't tried.
May 25 2009
parent reply Timo Gransch <timo.gransch web.de> writes:
MIURA Masahiro schrieb:


 Hi, I'm also looking forward to using debugger on Linux!


I tried dmd 1.045 on Arch Linux/i386 yesterday, and at least for my
small test, debugging with gdb worked OK with Phobos. But when I
switched to Tango, I got strange results again.

It's really a pity. These debugger issues on Linux keep me from using D
for my private projects up to now.

Best regards,
Timo
May 25 2009
parent MIURA Masahiro <echochamber gmail.com> writes:
Timo Gransch wrote:

 I tried dmd 1.045 on Arch Linux/i386 yesterday, and at least for my
 small test, debugging with gdb worked OK with Phobos. But when I
 switched to Tango, I got strange results again.


Hmm, I have failed using the patched GDB with DMD1/Phobos and DMD1/Tango.
Now I should make one more try.


 It's really a pity. These debugger issues on Linux keep me from using D
 for my private projects up to now.


I sympathize with you.  Ironically, Walter has a policy to listen to
enhancement requests only from actual users.  A chicken/egg problem.
So I chose to go with D2 without any debugger.
May 25 2009
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
Timo Gransch wrote:

 Hi everyone!
 
 I installed LDC on my Ubuntu 9.04/x86-64 system from the Launchpad Apt
 repository. So far it works great, but debugging is strange.
 
 I compile using
 
 ldc -g -debug test.d
 
 which should add symbolic debugger information to the executable, but
 when I run 'list' in gdb (original Debian/Ubuntu version as well as a
 self-compiled version with the current D patches) subsequently, I won't
 be shown the compiled source code, but obviously code from a lower
 level, which looks like
 
 159	 */
 160	int main(char[][] args);
 161	
 162	/***********************************
 163	 * Substitutes for the C main() function.
 164	 * It's purpose is to wrap the call to the D main()
 165	 * function and catch any unhandled exceptions.
 166	 */
 167	
 168	extern (C) int main(int argc, char **argv, char** env)
 (gdb)
 169	{
 (...)
 
 Is there any way to fix this? Do I need other parameters to compile?
 
 Best regards,
 Timo


Actually, I believe this is right. If you look in 
runtime/internal/dmain2.d:168, you will see that exact function. You 
will also see that it calls _Dmain (what you know as main()) further 
down in the function as a delegate. I have not had this issue when 
compiling with ldc, but the solution is probably to break at _Dmain 
rather than main. Another solution would be to compile the runtime 
without debug information, then gdb will use _Dmain anyway, as it is the 
first point it encounters debug info (This is probably why I don't have 
this issue, my runtime is compiled in release mode).

You might want to try updating ldc to one of the nightly builds (or 
0.9.1 when it's released), as debugging info is vastly improved over 
that of 0.9. Note that you should use ldmd instead of ldc when this 
happens (or learn the new syntax for ldc), as ldc has switched to llvm 
for command line parsing instead of dmd. This means -debug and -version 
(as well as a few others) will function differently unless you use ldmd.
May 25 2009
parent reply Timo Gransch <timo.gransch web.de> writes:
Robert Clipsham schrieb:


 			Another solution would be to compile the runtime 
 without debug information, then gdb will use _Dmain anyway, as it is the 
 first point it encounters debug info (This is probably why I don't have 
 this issue, my runtime is compiled in release mode).


Thanks a lot for your help, Robert.

I tried to compile ldc and the runtime (checked out from trunk) in
release mode, too, but it seems that I did something wrong.

In the ccmake interface, I set CMAKE_BUILD_TYPE to Release and removed
the -g switch from D_FLAGS (leaving -w;-d). After building, I compiled
my test programm using

ldmd -g -debug test.d

When running list in gdb, I got

(gdb) list
1	../sysdeps/x86_64/elf/start.S: No such file or directory.
	in ../sysdeps/x86_64/elf/start.S

When leaving the -g switch in D_FLAGS, list in gdb will show me the
contents of dmain2.d again.

Do I have to change any other configuration flags?

Best regards,
Timo
May 25 2009
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
Timo Gransch wrote:

 Do I have to change any other configuration flags?


Not as far as I'm aware. You could try using -O;-release to see if that 
makes a difference, but I don't know why you would get that error.
May 25 2009
prev sibling parent Timo Gransch <timo.gransch web.de> writes:
Timo Gransch wrote:


 When running list in gdb, I got

 (gdb) list
 1	../sysdeps/x86_64/elf/start.S: No such file or directory.
 	in ../sysdeps/x86_64/elf/start.S


Hi,

did anybody try to debug LDC 0.92 executables on Linux/x86-64? Using the 
binary version of the compiler, I still get the above message in gdb.

Best regards,
Timo
Mar 20 2010
prev sibling parent reply Timo Gransch <timo.gransch web.de> writes:
(Discussion about debugging ldc/x86-64 executables moved from
digitalmars.D.announce)

Christian Kamm wrote:


 can you try to make a breakpoint on the first line of your D main
 function (i.e. b myfile.d:15) and run to that?


(gdb) break test.d:5
Breakpoint 1 at 0x401e69: file test.d, line 5.
(gdb) run
Starting program: /home/timo/tmp/testd/test
[Thread debugging using libthread_db enabled]
[New Thread 0x7f0ce23146f0 (LWP 16164)]
[Switching to Thread 0x7f0ce23146f0 (LWP 16164)]

Breakpoint 1, D main (args={"/home/timo/tmp/testd/test"}) at test.d:5
5	    for (int i = 0; i < args.length; i++)
Current language:  auto; currently d
(gdb) step
7	        Cout(args[i] ~ "\n");
(gdb) step
0x00000000004052e0 in _d_newarrayvT ()
Current language:  auto; currently asm
(gdb) step
Single stepping until exit from function _d_newarrayvT,
which has no line number information.
0x0000000000409ef0 in typeinfo.ti_Ag.TypeInfo_Aa.next() ()

Best regards and thanks,
Timo
May 30 2009
parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
Timo Gransch wrote:

 Breakpoint 1, D main (args={"/home/timo/tmp/testd/test"}) at test.d:5
 5	    for (int i = 0; i < args.length; i++)
 Current language:  auto; currently d
 (gdb) step
 7	        Cout(args[i] ~ "\n");
 (gdb) step
 0x00000000004052e0 in _d_newarrayvT ()
 Current language:  auto; currently asm
 (gdb) step
 Single stepping until exit from function _d_newarrayvT,
 which has no line number information.
 0x0000000000409ef0 in typeinfo.ti_Ag.TypeInfo_Aa.next() ()


Well, that's what you would expect if you step into that line. Use 'next' to 
step over the runtime function calls hidden in that line.

Regards,
Christian
May 30 2009
parent reply Timo Gransch <timo.gransch web.de> writes:
Christian Kamm schrieb:


 Well, that's what you would expect if you step into that line. Use 'next' to 
 step over the runtime function calls hidden in that line.


Is it really intended that gdb tries to step into runtime functions
which have no debug information if I use 'step'? As you might have
realized, I'm not an expert in using the gdb command line (I prefer to
debug from my IDE), but if I run gdb on a C program compiled with gcc,
'step' stops at the lowest level of my own code.

The result is the same if I use 'next':

(gdb) break test.d:5
Breakpoint 1 at 0x401e69: file test.d, line 5.
(gdb) run
Starting program: /home/timo/tmp/testd/test
[Thread debugging using libthread_db enabled]
[New Thread 0x7fe5e63146f0 (LWP 27517)]
[Switching to Thread 0x7fe5e63146f0 (LWP 27517)]

Breakpoint 1, D main (args={"/home/timo/tmp/testd/test"}) at test.d:5
5	    for (int i = 0; i < args.length; i++)
Current language:  auto; currently d
(gdb) next
7	        Cout(args[i] ~ "\n");
(gdb) next
0x00000000004052e0 in _d_newarrayvT ()
Current language:  auto; currently asm
(gdb) next
Single stepping until exit from function _d_newarrayvT,
which has no line number information.
0x0000000000409ef0 in typeinfo.ti_Ag.TypeInfo_Aa.next() ()
(gdb) next
Single stepping until exit from function
_D8typeinfo5ti_Ag11TypeInfo_Aa4nextMFZC8TypeInfo,
which has no line number information.
0x00000000004052f4 in _d_newarrayvT ()

Best regards,
Timo
Jun 01 2009
parent Christian Kamm <kamm-incasoftware removethis.de> writes:
Timo Gransch wrote:

 Is it really intended that gdb tries to step into runtime functions
 which have no debug information if I use 'step'? As you might have
 realized, I'm not an expert in using the gdb command line (I prefer to
 debug from my IDE), but if I run gdb on a C program compiled with gcc,
 'step' stops at the lowest level of my own code.


When I debug C++ code with gdb, the behavior is the same:

Breakpoint 1, main () at debug.cc:5
5         C* c = new C;
(gdb) s
operator new (sz=1)
 at gcc-4.3.2/libstdc++-v3/libsupc++/new_op.cc:55
55  gcc-4.3.2/libstdc++-v3/libsupc++/new_op.cc: No such file or directory.
    gcc-4.3.2/libstdc++-v3/libsupc++/new_op.cc

i.e. it tries to step into the runtime function for C++'s new but fails.


 The result is the same if I use 'next':


Sounds like a bug. In a small test case, 'next' properly steps over the 
calls to _d_newarrayvT for me on x86-32. Could you make a ticket on 
http://www.dsource.org/projects/ldc with your test code?
Jun 01 2009