Debugging xm dump-core file

[Kieran Mansley <kmansley@solarflare.com>]

I'm following the instructions in xen-
unstable.hg/tools/debugger/gdb/README on how to use gdb to debug a
running guest or core file.  The former is fine, and I can connect to
the server, halt it, get a backtrace etc.  I'm having problems using gdb
and gdbserver-xen with a core file generated by xm dump-core however.

I do the following:

xm dump-core 1

gdbserver-xen 127.0.0.1:9999 --file /var/xen/dump/<corefile>

gdb /home/kjm/xen-unstable.hg/build-linux-2.6.18-xenU_x86_32/vmlinux

(gdb) directory /home/kjm/xen-unstable.hg/build-linux-2.6.18-xenU_x86_32/
Source directories searched: /home/kjm/xen-unstable.hg/build-linux-2.6.18-xenU_x86_32:$cdir:$cwd
(gdb) target remote 127.0.0.1:9999
Remote debugging using 127.0.0.1:9999
[New Thread 0]
[Switching to Thread 0]
0xc02def0a in _spin_lock_irqsave (lock=0xcd0f6bd4)
    at include2/asm/mach-xen/asm/spinlock.h:73
73              asm(__raw_spin_lock_string_flags : "+m" (lock->slock) : "r" (flags) : "memory");
warning: shared library handler failed to enable breakpoint
(gdb) bt
#0  0xc02def0a in _spin_lock_irqsave (lock=0xcd0f6bd4)
    at include2/asm/mach-xen/asm/spinlock.h:73
Cannot access memory at address 0xc0361b40


The last error (Cannot access memory at...) is the problem.  It means
that I can't get a back trace, and although I can see that the problem
I'm trying to debug is due to a spin lock, I'd rather worked that out
for myself and was hoping that gdb would be able to give me the
backtrace that would throw some light on my spin lock bug.

Anyone have any idea what I might have done wrong?  Getting a back trace
is such a basic operation that I'm sure it should work.

Thanks 

Kieran