On Thursday 17 May 2007 01:12, Jason Wessel wrote:
> 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.
If the single-step bit is cleared, user space execution will resume normally.
Once that happens, there is no way for gdb to forcefully get control back.
Worse still: during this userspace and subsequently kernel space resume, all
other processors may locked on kgdb entry.
One more problem is gdb removes breakpoints before a single step. So
user-space and then kernel-space code will execute without breakpoints with
this code.
Current kgdb code is definitely broken in this context. I believe we can't fix
it (either with following code or otherwise). We may be better off panicing
the way you'd done in yesterday's code.
-Amit
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
