Re: PPC KGDB changes and some help?

[Tom Rini]

On Mon, Jan 26, 2004 at 01:45:44PM -0800, George Anzinger wrote:

> Tom Rini wrote:
> >
> >>There is a real danger of passing signal info back to gdb as it will want 
> >>to try to deliver the signal which is a non-compute in most kgdbs in the 
> >>field.  I did put code in the mm-kgdb to do just this, but usually the 
> >>arrival of such a signal (other than SIGTRAP) is the end of the kernel.  
> >>All that is left is to read the tea leaves.
> >
> >
> >The gdb I've been testing this with knows better than to try and send a
> >singal back, so that's not a worry.  The motivation behind doing this
> >however is along the lines of "if it ain't broke, don't remove it".  The
> >original stub was getting all of this information correctly, so why stop
> >doing it?
> >
> You sure.  If so what gdb?  And how does it know?  I suppose you could tell 
> it with a script, but then what if one forgets?

GNU gdb 6.0 (MontaVista 6.0-8.0.4.0300532 2003-12-24)
Copyright 2003 Free Software Foundation, Inc.
[snip]

[New Thread 289]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 289]
0x00000000 in ?? ()
(gdb) c
Continuing.
Can't send signals to this remote system.  SIGSEGV not sent.

Noting that 0x0 is correct as the code that triggered this was:
static void (*dummy)(struct pt_regs *regs);
int drop_kgdb(void) {
        struct pt_regs regs;
        memset(&regs, 0, sizeof(regs));
        dummy(&regs);

        return 0;
}
module_init(drop_kgdb);

-- 
Tom Rini
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/