Re: [Kgdb-bugreport] [PATCH] Further fix to single step user->kernel

[Amit S. K. <ami...@li...>]

On Thursday 17 May 2007 22:34, Wessel, Jason wrote:
> > -----Original Message-----
> > From: Amit S. Kale [mailto:ami...@li...]
> > Sent: Thursday, May 17, 2007 11:38 AM
> > To: kgd...@li...
> > Cc: Wessel, Jason; Tom Rini
> > Subject: Re: [Kgdb-bugreport] [PATCH] Further fix to single
> > step user->kernel
> >
> >
> > 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.
>
> I was able to use gdb to break back in after the auto continue.

! Missed that.

>
> > 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.
>
> In the 6.6 release I used, gdb plants all the breakpoints prior to
> single step in the case that a single step results in a resume.

I wasn't aware. With this explanation this code looks lot better. While it's 
not ideal, I believe that's the best we can do at the moment.

ACK.
-Amit

>
> > 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
>
> Another possibility was to stop the kernel at the user space
> instruction.  I had tested that as well, and that made gdb happy, but
> you end up an instruction for which you can not back trace correctly
> because you have some arbitrary code in user land which has no fram
> pointer back to the under lying kernel code.  Originally that is why I
> thought a continue would be the best operation.
>
> Either way I still print a warning to explain what happened.
>
> Jason.