Re: ptrace single-stepping change breaks Wine

Jesse Allen
2004-11-22T23:19:48Z

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