[XenPPC] Accessing the Xen GDB-stub
As many of you know I've been looking at getting access to hypervisor
via the GDB stub in Xen. This is a brain dump, of what I learned trying
to get this tested.
Firstly a summary of GDB stub and technology available from Jimi, in
response to some confused queries from me.
<quote who="jimi" >
ok.. I can understand the confusion here so lets spell it out.
GDB can debug anything thru any channel. Typically it uses the ptrace (2)
syscall to debug an app on the same OS, however there is a remote protocol
that can go over any transport (socket, serial, etc...). The other end of the
transport is a small piece of code (we call the gdb-stub) accepts commands
over the transport and probes the machine. At a bare minimum, this code needs
to be able to read/write registers and read/write memory, the ability to
perform these functions we can call "the probe" and it provides the low lever
interface to the gdb-stub.
So, the gdb stub can be considered a translation layer between the
gdb protocol over some transport to the interfaces provided by "the
probe", the protocoal is documented here:
In our development there are quite a few stubs:
Mambo provides a gdb-stub that uses mambo internal "probing" interfaces so
gdb can debug whatever code the simulator is running.
2) HW probe
RiscWatch/JTAG gives us the ability to probe the CPU and memory. We have
some python code (xen/tools/gpproxy) that is a gdb-stub that attaches to the
3) Xen (and the code in Xen)
Xen will trap into an exception level debug handler (sort of like xmon) and
can "probe" the normal running state of Xen. This debug handler uses the
serial port to provide a gdb-stub so that gdb can debug Xen.
There are hypervisor calls that provide interfaces that can probe a DomU.
There is a a Dom0 application that provides a gdb-stub that uses these
hcalls to probe a DomU.
The rest of this email pertains to item 3, with real hardware and Mambo.
Step one : Build Xen with debugging and crash_dump
I build xen with:
make debug=y optimize=0 crash_debug=y \
CMDLINE="console=com1 gdb=com1 earlygdb=y" \
<< Any other args you need to get a working xen >>
Booting this xen binary will result in com1 being used for xen/dom0 consoles
and GDB. Also xen will trap into the GDB-stub quickly after boot:
(XEN) Physical RAM map:
(XEN) End of RAM: 512MB (524288kB)
(XEN) total_pages: 0x000000000001c000
(XEN) free_xenheap: 0x9000 - 0x400000
(XEN) Xen heap: 63MB (65500kB)
(XEN) free_xenheap: 0x6f7000 - 0x4000000
(XEN) free_xenheap: Go around the devtree: 0x6f7000 - 0x727000
(XEN) Domheap pages: 0x1ba00 442MB (452608kB)
(XEN) CPU #0: Hello World! SP = 471e00 TOC = 6e82c8 HID0 = 51018180000000
(XEN) GDB stub initialised.
(XEN) GDB connection activated.
(XEN) PC: 0x0000000000456dcc MSR: 0x9000000000021000
(XEN) LR: 0x0000000000456db4 CTR: 0x0000000000432f70
(XEN) CR: 0x24000084 XER: 0x00000000000fffff
<< skip 32 GPRs >>
(XEN) Waiting for GDB to attach...
Step two : Configure GDB
I've tested this with a range and GDBs (from 6.2.1 -> current CVS head). I
recommend 6.5. Current CVS head doesn't work with, but I don't think
its a Xen specific problem. I have the following in my .gdbinit file.
#set debug remote 1
set remotelogfile ~/tmp/gdb_remote.log
set remotetimeout 0
#show debug remote
Jimi also provides a .gdbinit file that explicitly tells GDB about some of Xen's
Step three : Connect.
If you're using Mambo the easiest way is to boot to this point and add an
additional and connect GDB to that. Something like:
mambo: after "(XEN) Waiting for GDB to attach..."
systemsim % mysim console create 0 inout listen 1234
(gdb) target remote :1234
systemsim % mysim go
If you're working with real hardware then you need a little bit of help. That's
where gdbproxy comes in. As the JS20s (and JS21s) don't have real serial
you need to connect to the blade console via SOL. I've written a application
"SOL-connect" that telnets to the blade management module, authenticates and
a console on the blade. I wrote this for my environment so it's needs to be
for each user/blade (sorry). "gdbproxy" itself spawns a connection proxy
(perhaps SOL-connect ;P) and then listens on port 1234 for a GDB to attach.
Aside from this complexity in connecting the XEN gdb-stub to a GDB process,
the stub seems to work, for all the minor testing I've played with.
If people think gdbproxy is useful, I'll clean it up and then provide a patch
set to add
it to xen.
I hope this helps. Please provide feedback and I'll place all this up on the
 Attached and at: http://bakeyournoodle.com/~tony/gdbproxy/
 Yes the password ends up in plain text in the binary!!
linux.conf.au http://linux.conf.au/ || http://lca2007.linux.org.au/
Jan 15-20 2007 The Australian Linux Technical Conference!
Description: Binary data
Xen-ppc-devel mailing list
|<Prev in Thread]
||[Next in Thread>|
- [XenPPC] Accessing the Xen GDB-stub,
Tony Breeds <=