Re: ptrace single-stepping change breaks Wine

[Linus Torvalds <torvalds@osdl.org>]

On Fri, 31 Dec 2004, Andi Kleen wrote:
> 
> 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.

Ehh, do you have any _alternatives_?

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

There is no complexity anywhere, and we don't actually emulate any 
instructions at all. The only thing we do is to check _whether_ the 
instruction is a "popf" - we let the CPU do all the work, we just say "ok, 
the instruction will set TF, so we should not touch it afterwards.

> 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.
 - 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.
 - you couldn't see the instruction after a system call.
 - ptrace returned bogus TF state after a single-step

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

I suspect all the code can be shared. In fact, the change to send a
SIGTRAP directly rather than play around with "ptrace_notify()" etc is
likely totally architecture-independent apart from the calling convention
magic, so all of "do_syscall_trace()" could probably be moved into
kernel/ptrace.c.

The _only_ real complexity is actually following the silly LDT
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.

I assume you have that same prefetch thing on x86-64 already, so if
anything, you could look at my replacement and see if it would be workable
to do the prefetch thing too..

IOW, none of the issues involved are new. 

			Linus