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