Re: ptrace single-stepping change breaks Wine

[Andi Kleen <ak@muc.de>]

Linus Torvalds <torvalds@osdl.org> writes:

> It's a bit more involved than I'd like, since especially the "popf" case 
> just is pretty complex, but I'd love to hear whether it works.
>
> NOTE NOTE NOTE! I've tested it, but only on one small test-case, so it 
> might be totally broken in many ways. I'd love to have people who are x86 
> and ptrace-aware give this a second look, and I'm confident Jesse will 
> find that it won't work, but can hopefully try to debug it a bit with 
> this..

Just looking at all this complexiy and thinking about
making it work on x86-64 too doesn't exactly give a good
feeling in my spine.

Not to belittle your archivement Linus but it all looks
very overengineered to me.

I think such complex instruction emulation games will be 
hard to maintain and there are very surely bugs in so 
much subtle code. 

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?

e.g. reporting TF after popf in ptrace doesnt really seem like a big
issue to me that is worth fixing with that much code.  It is more an
unimportant corner case, isnt it? Same thing with forcing TF after
popf.  I bet most debuggers in existence get this special case wrong
and so far the world hasn't collapsed because of that.

I would love to skip this all on x86-64, but I would prefer
to not make the behaviour incompatible to i386.

-Andi