On 10/24/05, Peter Beutner p.beutner@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=commi... [PATCH] x86_64: clean up ptrace single-stepping http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi...
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.
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