On 25/9/06 15:09, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote:
> 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);
>
On Sep 25, 2006, at 9:34 AM, Keir Fraser wrote:
On 25/9/06 14:27, "Jimi Xenidis" <[EMAIL PROTECTED]> 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
contr
On Sep 23, 2006, at 1:18 PM, Keir Fraser wrote:
On 22/9/06 4:07 pm, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote:
--text follows this line--
This patch allows the caller to find out if the gdbstub actually did
anything.
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
What different actions do
On 25/9/06 14:27, "Jimi Xenidis" <[EMAIL PROTECTED]> 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
On 22/9/06 4:07 pm, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote:
> --text follows this line--
>
> This patch allows the caller to find out if the gdbstub actually did
> anything.
>
> Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
What different actions do you envisage the caller will take? If the
