I solved the GPF problem I mentioned in an earlier e-mail (see the
information below the first patch).
The patch below is needed so the single step exception bits are
cleared. It was easiest to use the predefined handler exception routine
to do the
work of executing the continue if the KGDB is request to step from
kernel->user space. If there are no objections, I'll apply this patch
after the review period.
Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
Index: linux-2.6.21/arch/i386/kernel/kgdb.c
===================================================================
--- linux-2.6.21.orig/arch/i386/kernel/kgdb.c
+++ linux-2.6.21/arch/i386/kernel/kgdb.c
@@ -273,6 +273,7 @@ static int kgdb_notify(struct notifier_b
* eat the exception and continue the process
*/
printk(KERN_ERR "KGDB: trap/step from kernel to user
space, resuming...\n");
+ kgdb_arch_handle_exception(args->trapnr, args->signr,
args->err, "c","",regs);
return NOTIFY_STOP;
} else if (cmd == DIE_NMI_IPI || cmd == DIE_NMI ||
user_mode(regs) ||
(cmd == DIE_DEBUG &&
atomic_read(&debugger_active)))
Index: linux-2.6.21/arch/x86_64/kernel/kgdb.c
===================================================================
--- linux-2.6.21.orig/arch/x86_64/kernel/kgdb.c
+++ linux-2.6.21/arch/x86_64/kernel/kgdb.c
@@ -295,6 +295,7 @@ static int kgdb_notify(struct notifier_b
* eat the exception and continue the process
*/
printk(KERN_ERR "KGDB: trap/step from kernel to user
space, resuming...\n");
+ kgdb_arch_handle_exception(args->trapnr, args->signr,
args->err, "c","",regs);
return NOTIFY_STOP;
} else if (cmd == DIE_PAGE_FAULT || user_mode(regs) ||
cmd == DIE_NMI_IPI || (cmd == DIE_DEBUG &&
The real source of the GPF problem was a defect in gdb. If you execute
a "next" operation that needs to single step out of the current frame
and it results in
a continue inside KGDB, the next breakpoint that is hit will not have
the EIP decremented by 1 properly. gdb will continue single stepping
because it is still looking for the end of the frame. Ultimately you
will have some random fault. In my case it was a GPF due to the
instruction addresses being off by 1 and the "random code" was accessing
the machine in a bad way.
The following is not really the right way to fix gdb, but it the patch
illustrates the problem going away and that it is in fact gdb's fault.
Another way to fix this in gdb would be to calculate the next
instruction when single stepping and compare it with where the target
actually stopped and then check the breakpoint list.
No signed-off-by here because this is an example...
Index: gdb-6.6/gdb/infrun.c
===================================================================
--- gdb-6.6.orig/gdb/infrun.c
+++ gdb-6.6/gdb/infrun.c
@@ -1222,8 +1222,7 @@ adjust_pc_after_break (struct execution_
single-stepping in this case. */
if (ptid_equal (ecs->ptid, inferior_ptid) && currently_stepping
(ecs))
{
- if (prev_pc == breakpoint_pc
- && software_breakpoint_inserted_here_p (breakpoint_pc))
+ if (software_breakpoint_inserted_here_p (breakpoint_pc))
/* Hardware single-stepped a software breakpoint (as
occures when the inferior is resumed with PC pointing
at not-yet-hit software breakpoint). Since the
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
