On Thu, Dec 30, 2004 at 04:38:21PM -0800, Linus Torvalds wrote:
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.
Well, tough. I assume people who play with TF themselves know how to handle it without debuggers. Really adding instruction parsing for such a corner case seems like extreme overkill to me.
I agree it is not nice, but is it really worth all that complexity to hide it?
- 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.
Ok I see this as being a problem. But I bet it could be fixed much simpler without doing all this complicated and likely-to-be-buggy popf parsing you added.
- you couldn't see the instruction after a system call.
Are you sure?
- ptrace returned bogus TF state after a single-step
I am sure all debuggers in existence deal with that (and they will need to continue doing so because there are so many old kernels around)
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.
Yes, it was intentional to simplify it. 16bit code is not supposed to use prefetches (and even if they do the probability of faulting is pretty small) Also we needed several iterations to get all the subtle bugs out (and I bet there are some issues left)
-Andi