Re: ptrace single-stepping change breaks Wine

[Andi Kleen]

On Thu, Dec 30, 2004 at 04:38:21PM -0800, Linus Torvalds wrote:
> > Can someone repeat again what was wrong with the old ptrace
> > semantics before the initial change that caused all these complex
> > changes?  It seemed to work well for years. How about we just
> > go back to the old state, revert all the recent ptrace changes 
> > and skip all that?
> 
> Let me count the ways that were wrong before the changes:
>  - you couldn't debug any code that set TF. Really. ptrace would totally 
>    destroy the TF state in the controlled process, so it would do 
>    something totally different when debugged.

Well, tough. I assume people who play with TF themselves know
how to handle it without debuggers.  Really adding instruction
parsing for such a corner case seems like extreme overkill to me.

I agree it is not nice, but is it really worth all that complexity
to hide it?

>  - you couldn't even debug signal handlers, because they were _really_ 
>    hard to get into unless you knew where they were and put a breakpoint 
>    on them.

Ok I see this as being a problem. But I bet it could be fixed
much simpler without doing all this complicated and likely-to-be-buggy
popf parsing you added.

>  - you couldn't see the instruction after a system call.

Are you sure? 

>  - ptrace returned bogus TF state after a single-step

I am sure all debuggers in existence deal with that (and they will
need to continue doing so because there are so many old kernels around) 

> descriptors, and we actually do that (badly) in another place: the AMD
> "prefetch" check does exactly the same thing except it seems to get a few
> details wrong (looks like it cannot handle 16-bit code), and only works
> for the current process.

Yes, it was intentional to simplify it. 16bit code is not supposed
to use prefetches (and even if they do the probability of faulting
is pretty small) Also we needed several iterations
to get all the subtle bugs out (and I bet there are some issues left)

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/