Re: ptrace single-stepping change breaks Wine

[Jesse Allen <the3dfxdude@gmail.com>]

On Thu, 30 Dec 2004 14:46:17 -0800 (PST), Linus Torvalds
<torvalds@osdl.org> wrote:
> 
> 
> Ok, here's a patch that may or may not make Wine happier. It's a _lot_
> more careful about TF handling, and in particular it's trying really
> really hard to make sure that a controlling process does not change the
> trap flag as it is modified or used by the process.
> 
> This hopefully fixes:
> 
>  - single-step over "popf" should work - we won't clear TF after the popf,
>    but instead let the popf results remain.
> 
>    NOTE! I tried to make sure that it does the right thing for segments
>    with non-zero bases, but I never actually tested that code. It's fairly
>    obvious, but it's also fairly likely to have some silly problems. Wine
>    may well show effects of this, although I don't know how common
>    non-zero bases are with any kind of half-modern windows binaries.
> 
>  - ptrace reporting of "eflags" register after a single-step (we used to
>    report TF as being set because the debugger set it - even though the
>    "native state" without debugging had it cleared).
> 
>    This also hopefully means that all the conditional TF clearing games
>    etc aren't necessary, since arch/i386/kernel/traps.c should now be
>    taking care of hiding the debugger for most cases ("pushf" still
>    remains, and is hard. See comment in ptrace.c part of the patch)
> 
> 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..
> 

Well I tried this patch and it works.  I captured a log showing the
signals and eflags again when running the program.  I compared it to
the working version.  There are differences, but none seem to be the
scenario TF was not set when it should have been.  Both log files are
just about the same size too.  I captured a second log in a row, and
compared the previous.  Again there are differences, so there is some
unavoidable randomness.

Since I cannot spot any issue, the patch looks good.  Are there any
other test cases?

Jesse