WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [patch] common gdbstub issues

To: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [patch] common gdbstub issues
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Thu, 2 Mar 2006 16:12:19 -0600
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Delivery-date: Thu, 02 Mar 2006 22:13:10 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.3
This patch fixes up some issues I found when porting PPC to the new common gdb 
stub code:
- cosmetic changes in the messages printed
- 'flags' must always be unsigned long.
- explicitly calling initialize_gdb() is not difficult. For x86 and ia64 I 
placed this call immediately before do_initcalls(), since that's where it's 
being called from now so we know it's safe. Architecture people can move it 
earlier as appropriate.
- I don't understand all these ASSERT(!local_irq_is_enabled()) statements, 
sometimes bracketing a single call like receive_command(). How exactly would 
receive_command() manage to re-enable irqs? Also, a failing ASSERT would just 
call into the stub again anways...
- initialize_gdb() was overcomplicated. serial_parse_handle() already handles 
the parsing for us, and there's no need to panic there.

Please apply.

Signed-off-by: Hollis Blanchard <hollisb@xxxxxxxxxx>

diff -r 404fdd14c6d3 xen/arch/ia64/xen/xensetup.c
--- a/xen/arch/ia64/xen/xensetup.c      Tue Feb 28 20:57:06 2006
+++ b/xen/arch/ia64/xen/xensetup.c      Thu Mar  2 16:01:41 2006
@@ -333,6 +333,8 @@
     smp_cpus_done(max_cpus);
 #endif
 
+    initialize_gdb(); /* could be moved earlier */
+
     do_initcalls();
 printk("About to call sort_main_extable()\n");
     sort_main_extable();
diff -r 404fdd14c6d3 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c      Tue Feb 28 20:57:06 2006
+++ b/xen/arch/x86/setup.c      Thu Mar  2 16:01:41 2006
@@ -479,6 +479,8 @@
     printk("Brought up %ld CPUs\n", (long)num_online_cpus());
     smp_cpus_done(max_cpus);
 
+    initialize_gdb(); /* could be moved earlier */
+
     do_initcalls();
 
     schedulers_start();
diff -r 404fdd14c6d3 xen/common/gdbstub.c
--- a/xen/common/gdbstub.c      Tue Feb 28 20:57:06 2006
+++ b/xen/common/gdbstub.c      Thu Mar  2 16:01:41 2006
@@ -376,7 +376,6 @@
         break;
     case 'g': /* Read registers */
         gdb_arch_read_reg_array(regs, ctx);
-        ASSERT(!local_irq_is_enabled());
         break;
     case 'G': /* Write registers */
         gdb_arch_write_reg_array(regs, ctx->in_buf + 1, ctx);
@@ -395,7 +394,6 @@
             return 0;
         }
         gdb_cmd_read_mem(addr, length, ctx);
-        ASSERT(!local_irq_is_enabled());
         break;
     case 'M': /* Write memory */
         addr = simple_strtoul(ctx->in_buf + 1, &ptr, 16);
@@ -477,7 +475,7 @@
 {
     int resume = 0;
     int r;
-    unsigned flags;
+    unsigned long flags;
 
     if ( gdb_ctx->serhnd < 0 )
     {
@@ -506,7 +504,7 @@
 
     if ( !gdb_ctx->connected )
     {
-        printk("GDB connection activated\n");
+        printk("GDB connection activated.\n");
         gdb_arch_print_state(regs);
         gdb_ctx->connected = 1;
     }
@@ -522,7 +520,7 @@
 
     /* Shouldn't really do this, but otherwise we stop for no
        obvious reason, which is Bad */
-    printk("Waiting for GDB to attach to Gdb\n");
+    printk("Waiting for GDB to attach...\n");
 
     gdb_arch_enter(regs);
     gdb_ctx->signum = gdb_arch_signal_num(regs, cookie);
@@ -535,9 +533,7 @@
 
     while ( resume == 0 )
     {
-        ASSERT(!local_irq_is_enabled());
         r = receive_command(gdb_ctx);
-        ASSERT(!local_irq_is_enabled());
         if ( r < 0 )
         {
             dbg_printk("GDB disappeared, trying to resume Xen...\n");
@@ -545,9 +541,7 @@
         }
         else
         {
-            ASSERT(!local_irq_is_enabled());
             resume = process_command(regs, gdb_ctx);
-            ASSERT(!local_irq_is_enabled());
         }
     }
 
@@ -561,27 +555,14 @@
     return 0;
 }
 
-/*
- * initialization
- * XXX TODO
- *     This should be an explicit call from architecture code.               
- *     initcall is far too late for some early debugging, and only the 
- *     architecture code knows when this call can be made.          
- */
-static int
+int
 initialize_gdb(void)
 {
-    if ( !strcmp(opt_gdb, "none") )
-        return 0;
     gdb_ctx->serhnd = serial_parse_handle(opt_gdb);
-    if ( gdb_ctx->serhnd == -1 )
-        panic("Can't parse %s as GDB serial info.\n", opt_gdb);
-
-    printk("Gdb initialised.\n");
+    if ( gdb_ctx->serhnd != -1 )
+        printk("GDB stub initialised.\n");
     return 0;
 }
-
-__initcall(initialize_gdb);
 
 /*
  * Local variables:

-- 
Hollis Blanchard
IBM Linux Technology Center

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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [patch] common gdbstub issues, Hollis Blanchard <=