Messages in this thread | | | Date | Mon, 26 Jan 2004 15:06:51 -0700 | From | Tom Rini <> | Subject | Re: PPC KGDB changes and some help? |
| |
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(®s, 0, sizeof(regs)); dummy(®s);
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |