[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 eventuallyreturned control to you, versus the trap into the debugger being a simpleno-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? :DWe 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |