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-ppc-devel

Re: [Xen-devel] [PATCH][XEN] __trap_to_gdb should return something diffe

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][XEN] __trap_to_gdb should return something different
From: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>
Date: Mon, 25 Sep 2006 10:09:22 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 25 Sep 2006 07:09:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C13D9992.19AF%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <C13D9992.19AF%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Sep 25, 2006, at 9:34 AM, Keir Fraser wrote:




On 25/9/06 14:27, "Jimi Xenidis" <jimix@xxxxxxxxxxxxxx> wrote:

Currently there are two failure cases:
   1) GDB had no transport available for its use (UART or otherwise)
   2) "unexpected trap", usually another trap occurs while gdb is in
control

I suppose we could have (1) -EIO and (2) -EBUSY.
My logic was that either gdb was available or not and that I needed
to continue as if gdb was not enabled at all.

How would your behaviour differ if gdbstub actually ran and eventually
returned control to you, versus the trap into the debugger being a simple
no-op?

__trap_to_gdb() primary usage is to "respond" to the "program" exception that GDB caused because it inserted a trap in the text to serve as a breakpoint.

Surely the caller doesn't really care either way?
Uh oh, are we gonna have that "recovery" conversation again? :D
We find it _extremely_valuable_ to use GDB as a debugger/diagnostic and not just a post-mortem tool. We program in breakpoints and we even use do_debug_key() (which uses the poorly named debugger_trap_fatal()) to trap into the debugger, take a look around, continue execution and do not consider this as "fatal".

I understand the _broken_is_broken_ position and even chanted the "my debugger is printk()" several times myself, but this is a powerful tool, for those who wish to use it, and requires little support in the common code.

Here is the code that cares:

#ifdef CRASH_DEBUG
    if (__trap_to_gdb(regs, cookie) == 0)
        return;
#endif /* CRASH_DEBUG */

    printk("%s: type: 0x%lx\n", __func__, cookie);
    show_backtrace_regs(regs);
    machine_halt();

NOTE: we will revisit the call to machine_halt() later, we can't use panic() because right now we'll end up back in this fuction.

-JX


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