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?

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