This is fairly straightforward on -unstable using the gdbserver. I
submitted a README patch several weeks ago that never got committed.
I've included it below.
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/05/18 11:05:39-07:00 kmacy@octopus.eng.netapp.com
# add readme for domu_debug
# Signed-off-by: Kip Macy <kmacy@fsmware.com>
#
# BitKeeper/etc/logging_ok
# 2005/05/18 11:05:39-07:00 kmacy@octopus.eng.netapp.com +1 -0
# Logging to logging@openlogging.org accepted
#
# docs/misc/domu_debug.txt
# 2005/05/18 11:05:30-07:00 kmacy@octopus.eng.netapp.com +40 -0
#
# docs/misc/domu_debug.txt
# 2005/05/18 11:05:30-07:00 kmacy@octopus.eng.netapp.com +0 -0
# BitKeeper file
/t/raid-u37/users/XEN/latest/xeno-unstable.bk/docs/misc/domu_debug.txt
#
diff -Nru a/docs/misc/domu_debug.txt b/docs/misc/domu_debug.txt
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/docs/misc/domu_debug.txt 2005-05-17 11:11:14 -07:00
@@ -0,0 +1,40 @@
+For the moment xen must be re-built with domu_debug enabled in Rules.mk. The
+user-level stub gdbserver-xen is created by running gdbbuild in tools/gdb. The
+gdbbuild script currently assumes that bitkeeper installed.
+
+
+In domain 0, run as root
+> gdbserver-xen <name/ip-address>:<port> --attach <domid>
+my current dev box is curly and the new domain id is 1, so:
+> sudo gdbserver-xen curly:2345 --attach 1
+
+this will pause the domain until the gdb client tells it to continue.
+
+Either in domain 0 or on a separate machine run (unmodified) gdb:
+> gdb <symbol-file>
+so when debugging FreeBSD it is,
+> gdb kernel.debug
+GNU gdb 6.2
+Copyright 2004 Free Software Foundation, Inc.
+GDB is free software, covered by the GNU General Public License, and you are
+welcome to change it and/or distribute copies of it under certain conditions.
+Type "show copying" to see the conditions.
+There is absolutely no warranty for GDB. Type "show warranty" for details.
+This GDB was configured as "i386-unknown-freebsd5.2.1"...
+(gdb) target remote curly:2345
+...
+This will show you the line of code where it stopped.
+GDB will expect the path to the source to be the same as when you
+built the kernel, let me know if that isn't the case.
+'b <line>' will set a breakpoint at line in the current file
+'b <file>:<line>' will set a breakpoint in the specified file at the
+specified line
+'c' will continue
+'c n' will continue through the next n breakpoints
+'s' will single step
+'i r' will dump the registers
+'set $eax=5' will set eax to 5
+'p variable' will print the value of variable if it is in scope
+'i line *addr' will tell you what line of source code addr corresponds to
+'x/i addr' will decode the instruction at addr
+'x/10i addr' will decode 10 instructions starting at addr
On 6/22/05, Vishal Patil <vishpat@gmail.com> wrote:
> Hello
>
> I would like to know whether it is possible to debug a linux kernel
> under Xen using
> gdb. What I am specifically looking for, is that I should be able to
> run a linux kernel
> (xenU) and debug (set breakpoints, step etc) using gdb. It would be
> great if someone
> could point me to an example gdb session for kernel deugging.
> Thanks
>
> - Vishal
>
> --
> Intelligence, Aptitude, Interests, Ablity and Motivation are more a
> matter of personality than of genes
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users