Re: [Xen-devel] [PATCH] break-in to Xen 1) when gdb is invoked and 2) ^C on gdb

[Simon Horman <horms@xxxxxxxxxxxx>]

On Thu, Aug 20, 2009 at 10:37:05PM -0700, Caz Yokoyama wrote:
> Hello Simon,
> I afraid I don't understand your question. I assume your question is why I
> move the declaration of lsr from inside of while loop to outside. The reason
> is that I expect lsr is allocated and de-allocated every time the body of
> the while loop is executed. The speed of serial port is slow. Therefore,
> there may be no difference. Also gcc may optimize allocation and
> de-allocation moving toward outside of while loop.
> Let me know if I haven't answered your question.
> -caz

My question is, why are the following two lines included in your patch.
They don't seem to be necessary.

#if 1
#endif

> -----Original Message-----
> From: Simon Horman [mailto:horms@xxxxxxxxxxxx] 
> Sent: Thursday, August 20, 2009 5:24 PM
> To: Caz Yokoyama
> Cc: 'Keir Fraser'; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] break-in to Xen 1) when gdb is invoked and
> 2) ^C on gdb
> 
> On Mon, Aug 17, 2009 at 01:56:38PM -0700, Caz Yokoyama wrote:
> > Hello Keir,
> > This patch makes gdb break-in to Xen when 1) it is invoked and 2) ^C is
> > typed on gdb or clicking interrupt on ddd.
> > diff -r 8b0f1f37e145 xen/common/keyhandler.c
> > --- a/xen/common/keyhandler.c       Sun Aug 16 08:46:08 2009 +0100
> > +++ b/xen/common/keyhandler.c       Mon Aug 17 10:07:04 2009 -0700
> > @@ -397,7 +397,11 @@
> >      .desc = "print all diagnostics"
> >  };
> >  
> > +#if 1
> > +void do_debug_key(unsigned char key, struct cpu_user_regs *regs)
> > +#else
> >  static void do_debug_key(unsigned char key, struct cpu_user_regs *regs)
> > +#endif
> >  {
> >      printk("'%c' pressed -> trapping into debugger\n", key);
> >      (void)debugger_trap_fatal(0xf001, regs);
> > diff -r 8b0f1f37e145 xen/drivers/char/ns16550.c
> > --- a/xen/drivers/char/ns16550.c    Sun Aug 16 08:46:08 2009 +0100
> > +++ b/xen/drivers/char/ns16550.c    Mon Aug 17 10:07:04 2009 -0700
> > @@ -16,6 +16,7 @@
> >  #include <xen/serial.h>
> >  #include <xen/iocap.h>
> >  #include <asm/io.h>
> > +#include <xen/keyhandler.h>
> >  
> >  /*
> >   * Configure serial port with a string:
> > @@ -125,10 +126,16 @@
> >  {
> >      struct serial_port *port = dev_id;
> >      struct ns16550 *uart = port->uart;
> > +    char lsr;
> >  
> >      while ( !(ns_read_reg(uart, IIR) & IIR_NOINT) )
> >      {
> > -        char lsr = ns_read_reg(uart, LSR);
> > +        lsr = ns_read_reg(uart, LSR);
> > +#if 1
> 
> Is there a reason for #if 1 here?
> 
> > +        if ( lsr & LSR_BI ) { /* on BREAK */
> > +            do_debug_key('g', regs); /* g is meaningless */
> > +        }
> > +#endif
> >          if ( lsr & LSR_THRE )
> >              serial_tx_interrupt(port, regs);
> >          if ( lsr & LSR_DR )
> > diff -r 8b0f1f37e145 xen/include/xen/keyhandler.h
> > --- a/xen/include/xen/keyhandler.h  Sun Aug 16 08:46:08 2009 +0100
> > +++ b/xen/include/xen/keyhandler.h  Mon Aug 17 10:07:04 2009 -0700
> > @@ -40,6 +40,10 @@
> >      char *desc;
> >  };
> >  
> > +#if 1
> > +extern void do_debug_key(unsigned char key, struct cpu_user_regs *regs);
> > +#endif
> > +
> >  /* Initialize keytable with default handlers */
> >  extern void initialize_keytable(void);
> > 
> > Xen expects BREAK and 'g' which is the same sequence of the one on Linux
> > kernel. I submitted a patch which sends BREAK and 'g' to gdb-patches on
> > 08/07, but it is not approved yet.
> > You can't use ssplitd/nsplitd because it does not pass BREAK. Therefore,
> you
> > lose console output and corresponding ^A^A^A functions. My associated
> lines
> > for the patch are
> > menu.lst
> >         kernel /boot/xen-3.5-unstable.gz com1=115200,8n1 gdb=com1 
> > .gdbinit
> >     set remotebreak BREAK-g
> >     target remote /dev/ttyS0
> >  ddd --gdb --debugger "/home/caz/lightfleet/kgdb/gdb-KgdbLight/gdb/gdb"
> > xen/xen-syms
> > -caz
> > 
> 
> 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

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