[Xen-ia64-devel] [Patch] Support domU of coredump on ia64

2006-07-21 Thread Akio Takebe
Hi,

This patch support domU of coredump on ia64.
xen_panic_event() is registered to panic_notifier_list,
and xen_panic_event() call HYPERVISOR_shutdown(SHUTDOWN_crash) 
at panic time.
If xend notify crashed status, xend call dumpCore()
and create domU's core in /var/xen/dump.

Signed-off-by: Akio Takebe [EMAIL PROTECTED]

I tested the following step
(I used a attached crash.c to panic domU.)

1. xm create -c domU
2. insmod crash.ko  (in domU)
3. checked /var/xen/dump and there was domU's core.
   I check domU's core by using size and strings.

Best Regards,

Akio Takebe

dumpcore.patch
Description: Binary data


crash.c
Description: Binary data


Makefile
Description: Binary data
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Re: [Xen-ia64-devel] [Patch] Support domU of coredump on ia64

2006-07-21 Thread Tristan Gingold
Le Vendredi 21 Juillet 2006 12:14, Akio Takebe a écrit :
 Hi,

 This patch support domU of coredump on ia64.
 xen_panic_event() is registered to panic_notifier_list,
 and xen_panic_event() call HYPERVISOR_shutdown(SHUTDOWN_crash)
 at panic time.
 If xend notify crashed status, xend call dumpCore()
 and create domU's core in /var/xen/dump.

 Signed-off-by: Akio Takebe [EMAIL PROTECTED]

 I tested the following step
 (I used a attached crash.c to panic domU.)

 1. xm create -c domU
 2. insmod crash.ko  (in domU)
 3. checked /var/xen/dump and there was domU's core.
I check domU's core by using size and strings.
Hi Akio and everyone!

recently I started to work on debugger.  Attached is the current work.
I was able to stop a domain and disp under gdb the current ip.
Backtrace is not working.  I suppose it requires the ar.bsp value which has to 
be computed.
Also I didn't try on core images.

I am not yet planning to continue this work now.  If anyone wants to continue 
please tell.

Tristan.
diff -r b2abc70be89e tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/gdbserver/configure.srv
--- a/tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/gdbserver/configure.srv	Wed Jul 19 07:17:54 2006 -0600
+++ b/tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/gdbserver/configure.srv	Fri Jul 21 11:56:08 2006 +0200
@@ -30,7 +30,7 @@ case ${target} in
 			srv_linux_thread_db=yes
 			;;
   ia64-*-linux*)	srv_regobj=reg-ia64.o
-			srv_tgtobj=linux-low.o linux-ia64-low.o
+			srv_tgtobj=linux-xen-low.o linux-ia64-low.o
 			srv_linux_usrregs=yes
 			;;
   m68*-*-linux*)	srv_regobj=reg-m68k.o
diff -r b2abc70be89e tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/gdbserver/linux-xen-low.c
--- a/tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/gdbserver/linux-xen-low.c	Wed Jul 19 07:17:54 2006 -0600
+++ b/tools/debugger/gdb/gdb-6.2.1-xen-sparse/gdb/gdbserver/linux-xen-low.c	Fri Jul 21 11:56:08 2006 +0200
@@ -37,6 +37,7 @@
 #include errno.h
 #include xenctrl.h
 #include thread_db.h
+#define XC_PTRACE_PRIVATE
 #include xc_ptrace.h
 
 #define TRACE_ENTER /* printf(enter %s\n, __FUNCTION__) */
@@ -68,7 +69,6 @@ static int expect_signal = 0;
 static int expect_signal = 0;
 static int signal_to_send = 0; 
 static void linux_resume (struct thread_resume *resume_info);
-static void linux_set_inferior (void);
 
 int debug_threads;
 int using_threads;
@@ -83,45 +83,15 @@ struct pending_signals
 #define PTRACE_ARG3_TYPE long
 #define PTRACE_XFER_TYPE long
 
+#ifdef HAVE_LINUX_REGSETS
 static int use_regsets_p = 1;
+#endif
 
 
 #define pid_of(proc) ((proc)-head.id)
 
 /* FIXME: Delete eventually.  */
 #define inferior_pid (pid_of (get_thread_process (current_inferior)))
-
-/* This function should only be called if the process got a SIGTRAP.
-   The SIGTRAP could mean several things.
-
-   On i386, where decr_pc_after_break is non-zero:
-   If we were single-stepping this process using PTRACE_SINGLESTEP,
-   we will get only the one SIGTRAP (even if the instruction we
-   stepped over was a breakpoint).  The value of $eip will be the
-   next instruction.
-   If we continue the process using PTRACE_CONT, we will get a
-   SIGTRAP when we hit a breakpoint.  The value of $eip will be
-   the instruction after the breakpoint (i.e. needs to be
-   decremented).  If we report the SIGTRAP to GDB, we must also
-   report the undecremented PC.  If we cancel the SIGTRAP, we
-   must resume at the decremented PC.
-
-   (Presumably, not yet tested) On a non-decr_pc_after_break machine
-   with hardware or kernel single-step:
-   If we single-step over a breakpoint instruction, our PC will
-   point at the following instruction.  If we continue and hit a
-   breakpoint instruction, our PC will point at the breakpoint
-   instruction.  */
-static CORE_ADDR
-get_stop_pc (void)
-{
-  CORE_ADDR stop_pc = (*the_low_target.get_pc) ();
-
-  if (get_thread_process (current_inferior)-stepping)
-return stop_pc;
-  else
-return stop_pc - the_low_target.decr_pc_after_break;
-}
 
 static void *
 add_process (int pid, long tid)
@@ -252,6 +222,7 @@ linux_resume (struct thread_resume *resu
 }
 
 
+#ifdef HAVE_LINUX_REGSETS
 static int
 regsets_fetch_inferior_registers ()
 {
@@ -355,29 +326,126 @@ regsets_store_inferior_registers ()
 }
   return 0;
 }
-
-
+#endif /* HAVE_LINUX_REGSETS */
+
+#ifdef HAVE_LINUX_USRREGS
+
+static int
+register_addr (int regnum)
+{
+  int addr;
+
+  if (regnum  0 || regnum = the_low_target.num_regs)
+error (Invalid register number %d., regnum);
+
+  addr = the_low_target.regmap[regnum];
+
+  return addr;
+}
+
+/* Fetch one register.  */
+static void
+fetch_register (int regno, struct gdb_regs *regs)
+{
+  CORE_ADDR regaddr;
+
+  regaddr = register_addr (regno);
+  if (regaddr == -1)
+return;
+  fprintf (stderr, fetch_register %d : off=%d = %016lx\n,
+	   regno, regaddr, *((unsigned long *)((char *)regs + regaddr)));
+  supply_register (regno, (char *)regs + regaddr);
+}
+
+/* Fetch all registers, or just one, from the child process.  */
+static 

Re: [Xen-ia64-devel] Problems booting 2 vm!

2006-07-21 Thread Tristan Gingold
Le Vendredi 21 Juillet 2006 15:50, Rodrigo Lord a écrit :
 Hi!

 I`m testing xen-ia64 on an Itanium2 rx2600 (hp integrity) with 4
 processors.

 but an error shows some times (in vm01 and dom0 too):

 kernel unaligned access to 0xe0005ec2201e, ip=0xa0010093d111
 kernel unaligned access to 0xe0005ec2201e, ip=0xa0010093d1d1
 kernel unaligned access to 0xe0005ec2201e, ip=0xa0010093d260
 kernel unaligned access to 0xe0005ec2202e, ip=0xa0010093d4e0
 kernel unaligned access to 0xe0005ec2202e, ip=0xa0010093b9c1
This is harmless.

 Other problem: just boots 1 virtual machine! (when I try to boot 2 vm, the
 system hangs)...
 I don`t know how to capture this error to post here!
Difficult to say without details!

Check memory usage: 'xm info' before 'xm create'; amount of memory for vm 
#2...

Tristan.

___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel