On Sun, Nov 21, 2004 at 10:23:41PM -0800, Linus Torvalds wrote:
Ok, how about this patch?
It does basically two things:
it makes the x86 version of ptrace be a lot more careful about the TF bit in eflags, and in particular it never touches it _unless_ the tracer has explicitly asked for it (ie we set TF only when doing a PTRACE_SINGESTEP, and we clear it only when it has been set by us, not if it has been set by the program itself).
This patch also cleans up the codepaths by doing all the common stuff in set_singlestep()/clear_singlestep().
It clarifies signal handling, and makes it clear that we always push the full eflags onto the signal stack, _except_ if the TF bit was set by an external ptrace user, in which case we hide it so that the tracee doesn't see it when it looks at its stack contents.
It also adds a few comments, and makes it clear that the signal handler itself is always set up with TF _clear_. But if we were single-stepped into it, we will have notified the debugger, so the debugger obviously can (and often will) decide to continue single-stepping.
IMHO, this is a nice cleanup, and it also means that I can actually debug my "program from hell":
[torvalds@evo ~]$ gdb ./a.out GNU gdb Red Hat Linux (6.1post-1.20040607.41rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) run Starting program: /home/torvalds/a.out Reading symbols from shared object read from target memory...(no debugging symbols found)...done. Loaded system supplied DSO at 0xffffe000 (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGTRAP, Trace/breakpoint trap. 0x08048480 in main () (gdb) signal SIGTRAP Continuing with signal SIGTRAP.
Program received signal SIGTRAP, Trace/breakpoint trap. 0x08048487 in main () (gdb) signal SIGTRAP Continuing with signal SIGTRAP.
Program received signal SIGTRAP, Trace/breakpoint trap. 0x08048488 in smc () (gdb) signal SIGTRAP Continuing with signal SIGTRAP. Copy protected: ok
Program exited with code 01. (gdb)
which I think is a sign that this patch actually fixes ptrace.
Does this help with wine? I dunno. Maybe some wine people can comment..
For the wine app in question, it does make a difference. However, there is a new problem. The program gets stuck at the loading screen at 100% CPU. It's making a call to select, timing out, and then tries select again, repeats. It's waiting for something that seems to never happen.
I've captured a log, "loop.log.bz2", and shortened to have only the relevent information after the CMS32_MUTEX is created. Look for occurances of "select()" -- I think the second one is where it starts. It's on my ftp if anyone wants to take a look. It probably can be compared to the working- version log where this doesn't occur, but it might be a pain to spot the working particular instance.
Jesse