[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.