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
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
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 hav
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
> 0x004052e0 in _d_newarrayvT ()
> Current lan
(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.
(gd
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
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.
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
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
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 debugg
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
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/U
12 matches
Mail list logo
