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