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 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 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 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.  http://sources.redhat.com/gdb/current/onlinedocs/gdb_33.html#SEC664  Attached and at: http://bakeyournoodle.com/~tony/gdbproxy/  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!
Description: Binary data
_______________________________________________ Xen-ppc-devel mailing list Xenemail@example.com http://lists.xensource.com/xen-ppc-devel