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
|
Home