Re: ptrace single-stepping change breaks Wine

Linus Torvalds
2004-12-31T00:38:57Z

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