Yeah; sometimes it will generate that error in the middle of
single-stepping over something larger, though, and it breaks you out of
whatever you were doing.
> > Shouldn't be that hard to fix this up in ptrace, though.
>
> Or even in user space, since the high pages are all the same in all
> processes (so gdb doesn't even strictly need ptrace, it can just read it's
> _own_ codespace there). But yeah, we could make ptrace aware of the magic
> pages.
I need to get back to my scheduled ptrace cleanups. Meanwhile, here's
a patch to do this. Completely untested, like all good patches; but
it's pretty simple.
===== arch/i386/kernel/ptrace.c 1.17 vs edited =====
--- 1.17/arch/i386/kernel/ptrace.c Wed Nov 27 18:14:11 2002
+++ edited/arch/i386/kernel/ptrace.c Thu Dec 19 21:33:37 2002
@@ -21,6 +21,7 @@
#include <asm/processor.h>
#include <asm/i387.h>
#include <asm/debugreg.h>
+#include <asm/fixmap.h>
/*
* does not yet catch signals sent when the child dies.
@@ -196,6 +197,18 @@
case PTRACE_PEEKDATA: {
unsigned long tmp;
int copied;
+
+ /* Allow ptrace to read from the vsyscall page. */
+ if (addr >= FIXADDR_START && addr < FIXADDR_TOP &&
+ (addr & 3) == 0) {
+ int idx = virt_to_fix (addr);
+ if (idx == FIX_VSYSCALL) {
+ tmp = * (unsigned long *) addr;
+ ret = put_user (tmp, (unsigned long *) data);
+ break;
+ }
+ }
+
copied = access_process_vm(child, addr, &tmp, sizeof(tmp), 0);
ret = -EIO;
-- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer - 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/