Stack tracing on Linux ?

[Georg Wrede]

With gdb I can either debug a core dump or an actual running process. 
For example, with

import std.stdio;

int main()
{
     readWrite();
     return 8;
}

void readWrite()
{
     auto line = readln();   // here it waits, and that's when I debug
                             // in another window
     write("Rivi oli: ", line);
}

I get the following stack trace (it looks the same whether I debug a 
core dump or a running instance)

#0  0x00251416 in __kernel_vsyscall ()
#1  0x00591a93 in __read_nocancel () from /lib/libc.so.6
#2  0x00528cee in _IO_new_file_underflow (fp=0x62e420) at fileops.c:598
#3  0x0052c17a in __underflow (fp=0x62e420) at genops.c:361
#4  0x0051e648 in _IO_getdelim (lineptr=0xbf94ec8c, n=0xbf94ec90,
     delimiter=10, fp=0x62e420) at iogetdelim.c:79
#5  0x080505bb in _D3std5stdio6readlnFPS3std1c5stdio6_iobufKAawZk ()
#6  0x080504d0 in _D3std5stdio6readlnFPS3std1c5stdio6_iobufwZAya ()
#7  0x0804931a in _D5read29readWriteFZv ()
#8  0x00000000 in ?? ()

This is not perfect, 5..7 are functions written in D, but main is 
missing. Then, trying to examine a core dump from something that gets a 
segfault, I wrote the following, expecting that I'd get a grandiose 
stack trace


$ cat npe.d
import std.stdio;

int main()
{
     return foo(3);
}

int foo(int a)
{
     return 1 + bar(a - 3);
}

int bar(int b)
{
     return 1 + car(b - 3);
}

int car(int c)
{
     return 1 + dar(c - 3);
}

int dar(int d)
{
     return 1 + * cast(int*) d; // null pointer exception
}



Turns out I got zilch!

#0  0x08049118 in _D3npe3darFiZi ()
#1  0xfffffffa in ?? ()

I have DMD on Fedora 10, and used
dmd -g -debug -v read2.d
to compile. Incidentally, using
dmd -gc -debug -v read2.d
does seem to give the same stack trace.