wine ptrace trouble

Jesse Allen the3dfxdude at gmail.com
Mon Oct 24 10:30:18 CDT 2005


On 10/24/05, Peter Beutner <p.beutner at gmx.net> wrote:
> Jesse Allen schrieb:
> >
> > I discovered this issue on x86 on linux 2.6.8/9 which led Linus to
> > fixing by 2.6.11.   Andi Kleen has not ported the patch to x86-64 from
> > what I know, so wine will still suffer under it  -- ie single stepping
> > into signal handlers, see mailing list archives.  You need to get your
> > kernel patched to fix the problem.  I have access to x86-64 systems
> > now and may be able to help.
> >
>
> he ported at least parts of Linus fixes.
>
> [PATCH] x86_64: Handle programs that set TF in user space using popf while single stepping
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e502cdd63de666832b3b65017bb607c22d2868de
> [PATCH] x86_64: clean up ptrace single-stepping
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=aa85b9af5bdae1f8b84d80367324e4410c3f0674
>
> Appearently not enough :/
>
>



Thanks for the links.  Now we need to determine what has and hasn't
changed since.  Luckily I've kept most of the information I gathered
originally.

http://www.chez.com/alors/

The first link is an archive ptrace.tar.gz I uploaded that contains
the three patches that caused the regression, two test cases (assembly
output of one), and descriptions of cpu flag registers.  Notice the
patches modify x86-64... one of which touches PTRACE_CONT.  The one
test case was created by David Lebenzi  (sorry if I got the wrong
name)  for one of the patches.  The other was created by Linus to
describe the bug I found.  Both test cases must work correctly for a
properly fixed kernel.

The logs are from 2.6.10 (and pre)  which were because there were
multiple bugs, and we hadn't got everything yet (remember I said
2.6.11 was fixed).  I believe this is what prompted the "is_at_popf()"
you see in the links you posted.  I can't remember what they contain
so these are probably no longer useful.  I could probably dig up
patches and emails too as I get time.

One thing I did to figure out the problem was to print traces of the
flag register in wine everytime before it called the kernel and after
return.  Then I ran it both on a working kernel, and not-working
kernel, and compared both.  That's how I finally figured it out.

Anyways, if you notice the regression patch touches PTRACE_CONT and
neither of the two patches does anything with
arch/x86_64/kernel/signal.c, so we are probably missing something.  We
need to look up the original patch that fixes
arch/i386/kernel/signal.c, however I need to get to school =/

Jesse



More information about the wine-devel mailing list