Re: [Xen-devel] how to debug xen?

["Yan Li" <yan_li00@xxxxxxxxxxx>]

hi

Thanks,but now I'm stuck. I wanna try nsplitd first. so I do it according to
the Debugger-howto. I built xen and xeno with -g added and
fomit-frame-pointer
disabled.

The problem is I'm really confused by the configuration of nsplitd.

1.it said set 'pdb=xxx'. How can I tell which port I'm connecting to?

2.in nsplitd configuration.
  what are the /etc/xinetd.d/nsplit and all the 'wcons00', 'wanda remote
console,
  stuff? I'm asuming it's in configuration in their working machine. Then
can
  anyone tell me what does this mean?
  The whole nsplitd configuration section,please let me know the details
about it.
  I totally have no idea what's going on there.

  For example, I have two machines, A.x.x.x, B.x.x.x, I'm running xen on
machine A,
  using machine B to connect to the serial line. What should all the
settings look
  like?

btw, David, is the socat just this one: http://www.socat.org/?

Thanks a lot!

Q
----- Original Message ----- 
From: "Kip Macy" <kmacy@xxxxxxxxxxxxxxx>
To: "David Becker" <becker@xxxxxxxxxxx>
Cc: "Yan Li" <yan_li00@xxxxxxxxxxx>; <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, July 23, 2004 8:08 AM
Subject: Re: [Xen-devel] how to debug xen?


> One non-obvious thing that I didn't see in the docs is that if you use
> multiple nsplitds they have to be spaced 4 ports apart not 2.
>
> -Kip
>
>
>
> On Fri, 23 Jul 2004, David Becker wrote:
>
> >
> > " How to debug xen? just use the nsplitd as XenDebugger-HOWTO said? It
seems
> > " quite tricky. I believe lots of people are doing development on xen,
so
> > " usually how to debug it?
> >
> > This is how I debug xen.  The starting point is reading
> >     xeno-unstable.bk/docs/HOWTOs/XenDebugger-HOWTO
> > I do not use nsplitd.
> >
> > First, build debug kernels.
> > For xen, in the xeno-unstable.bk/xen directory add this to
arch/x86/Rules.mk
> >         CFLAGS += -g
> >     and build xen saying
> >         make debugger=y
> > For xenolinux,  in xeno-unstable.bk/linux-2.4.26-xen0
> >     turn on CONFIG_FRAME_POINTER (in the Kernel Hacking section of
> >         menuconfig or xconfig)
> >     in Makefile put -g into CFLAGS_KERNEL (line 52)
> >         CFLAGS_KERNEL = -g
> >     and build xenolinux with
> >         make ARCH=xen bzImage
> >
> >
> > Second, find a target machine with some serial lines.
> > I prefer virtual machines and use VMware Workstation 4.5 on Linux (4.0
didn't
> > work, btw).  In the vmware Machine Settings, config both com1 and com2
> > to be named pipes with "This end is the client" and "The other end is a
> > virtual machine".   Run two socat jobs in the background
> > to convert the pipes to ptys:
> >     socat UNIX-LISTEN:/tmp/com1pipe,unlink-early,fork pty,link=/tmp/com1
&
> >     socat UNIX-LISTEN:/tmp/com2pipe,unlink-early,fork pty,link=/tmp/com2
&
> >
> >
> > Third, boot the target machine and connect the debugger.
> > Put the debug xen and xenolinux on the machine.  In the grub menu.lst
> > file, add the serial lines and pdb to the xen command line:
> >    kernel /boot/xen.gz.debug dom0_mem=100000 ifname=eth0 com1=9600,8n1
com2=9600,8n1 pdb=com2
> > Boot it up and connect to the console.  In my vmware setup, I connect
> > to com1 from the machine hosting VMware with
> >     kermit -c -l /tmp/com1
> > Then on com1 type ^A^A^A to make xen listen to console cmds.
> > At this point type 'h' and see if the 'D' command is listed.  If not,
> > pdb is missing so make sure the xen being run was built with debugger=y.
> > Hit 'D' on the console to make xen drop into the debugger.
> >
> > >From the machine listening to the serial lines, connect to the target
machine
> > with gdb and the xen-syms file and check if was built with -g by trying
to
> > list a function:
> >     $ gdb xeno-unstable.bk/xen/xen-syms
> >     (gdb) list do_dom0_op
> >     26      extern unsigned int alloc_new_dom_mem(struct domain *,
> >     unsigned int);
> >     27      extern long arch_do_dom0_op(dom0_op_t *op, dom0_op_t
> >     *u_dom0_op);
> >     28      extern void arch_getdomaininfo_ctxt(struct domain *,
> >     full_execution_context_t *);
> >     29
> >     30      long do_dom0_op(dom0_op_t *u_dom0_op)
> >     31      {
> >     32          long ret = 0;
> >     33          dom0_op_t curop, *op = &curop;
> >     34
> >     35          if ( !IS_PRIV(current) )
> >     (gdb) target remote /tmp/com2
> > Now you can debug xen itself.  Note that the breakpoint is in xenolinux
> > so gdb will be cryptic about the current function and stacktrace.  Put a
> > breakpoint in xen somewhere and continue to get gdb to a function is can
> > decode.
> >
> > To debug xenolinux, drop to the debugger:
> >    (gdb) set pdb_ctx.domain=0
> >    (gdb) set pdb_ctx.valid=1
> >    (gdb) add-symbol-file xeno-unstable.bk/linux-2.4.26-xen0/vmlinux
> > Now you can debug vmlinux itself (except where the xen and linux
> > symbols clash).
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by BEA Weblogic Workshop
> > FREE Java Enterprise J2EE developer tools!
> > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
> >
>


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel