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