[XenPPC] Accessing the Xen GDB-stub

Hello All,
        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[1]
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:
1) Mambo/Systemsim
   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
   HW probe.

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.

4) Dom0/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.
</quote >

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:
---
<snip>
(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
show remotelogfile
show remotetimeout
---

Jimi also provides a .gdbinit file that explicitly tells GDB about some of Xen's
quirks at:
http://lists.xensource.com/archives/html/xen-ppc-devel/2006-06/msg00271.html

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..."
  [^C mambo]
  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[2] comes in.  As the JS20s (and JS21s) don't have real serial 
ports
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[3] and 
opens
a console on the blade.  I wrote this for my environment so it's needs to be 
customised
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 
wiki.

[1] http://sources.redhat.com/gdb/current/onlinedocs/gdb_33.html#SEC664
[2] Attached and at: http://bakeyournoodle.com/~tony/gdbproxy/
[3] Yes the password ends up in plain text in the binary!!

Yours Tony

   linux.conf.au       http://linux.conf.au/ || http://lca2007.linux.org.au/
   Jan 15-20 2007      The Australian Linux Technical Conference!

gdbproxy-0.0.1a.tar.bz2
Description: Binary data

_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel

WARNING - OLD ARCHIVES

xen-ppc-devel

[XenPPC] Accessing the Xen GDB-stub