Re: wine ptrace trouble

[Jesse Allen]

On 10/23/05, Peter Beutner  wrote:
> hmm it appearently is a kernel/ptrace issue as Marcus Meissner supposed.
> I just tested it on x86 and it works fine, while on x86_64 it doesnt work.
> I will dig a bit further if time permits.
>
> Just out of curiosity, why does the server continue ptracing after "the work is done",
> instead of just detaching?

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.

wine ptrace trouble

[Peter Beutner]

Jesse Allen schrieb:
> On 10/23/05, Peter Beutner  wrote:
> > hmm it appearently is a kernel/ptrace issue as Marcus Meissner supposed.
> > I just tested it on x86 and it works fine, while on x86_64 it doesnt work.
> > I will dig a bit further if time permits.
> >
> > Just out of curiosity, why does the server continue ptracing after "the work is done",
> > instead of just detaching?
>
> 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 :/

wine ptrace trouble

[Jesse Allen]

On 10/24/05, Peter Beutner  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.

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

wine ptrace trouble

[Jesse Allen]

The regression occurred between 2.6.8 and 9.  One thing to do is to
try 2.6.8 which works on x86 and see if your problem goes away if
indeed it's the same problem.

wine ptrace trouble

[Peter Beutner]

Jesse Allen schrieb:
> 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.
> [..]

thx for all the infos.
I managed to track down the missing pieces in the kernel. The mentioned ptrace fix wasnt
applied to the ia32 emulation code under x86_64. I already send a patch to lkml:
http://lkml.org/lkml/2005/10/24/198

A attach the patch again in case anyone wants to try it.

Be more careful with TF handling to fix some copy protection codes in Wine

patch originally for i386 by Linus, then ported to x86_64 by Andi Kleen
see [PATCH] x86_64: Some fixes for single step handling
commit: be61bff789fe44bfb6d9282d8f7eccc860bdcfb6

But it was never applied to the ia32 emulation code which breaks again some
copy-protection schemes under wine when running on x86_64.

Signed-off-by: Peter Beutner

--- linux-2.6/arch/x86_64/ia32/ia32_signal.c.old	2005-10-25 00:52:29.000000000 +0200
+++ linux-2.6/arch/x86_64/ia32/ia32_signal.c	2005-10-25 00:52:59.000000000 +0200
@@ -353,7 +353,6 @@ ia32_setup_sigcontext(struct sigcontext_
    	 struct pt_regs *regs, unsigned int mask)
 {
    int tmp, err = 0;
-	u32 eflags;

tmp = 0;
    __asm__("movl %%gs,%0" : "=r"(tmp): "0"(tmp));
@@ -378,10 +377,7 @@ ia32_setup_sigcontext(struct sigcontext_
    err |= __put_user(current->thread.trap_no, &sc->trapno);
    err |= __put_user(current->thread.error_code, &sc->err);
    err |= __put_user((u32)regs->rip, &sc->eip);
-	eflags = regs->eflags;
-	if (current->ptrace & PT_PTRACED)
-		eflags &= ~TF_MASK;
-	err |= __put_user((u32)eflags, &sc->eflags);
+	err |= __put_user((u32)regs->eflags, &sc->eflags);
    err |= __put_user((u32)regs->rsp, &sc->esp_at_signal);

tmp = save_i387_ia32(current, fpstate, regs, 0);
@@ -505,13 +501,9 @@ int ia32_setup_frame(int sig, struct k_s
    regs->ss = __USER32_DS;

set_fs(USER_DS);
-	if (regs->eflags & TF_MASK) {
-		if (current->ptrace & PT_PTRACED) {
-			ptrace_notify(SIGTRAP);
-		} else {
-			regs->eflags &= ~TF_MASK;
-		}
-	}
+    regs->eflags &= ~TF_MASK;
+    if (test_thread_flag(TIF_SINGLESTEP))
+        ptrace_notify(SIGTRAP);

#if DEBUG_SIG
    printk("SIG deliver (%s:%d): sp=%p pc=%p ra=%p\n",
@@ -605,13 +597,9 @@ int ia32_setup_rt_frame(int sig, struct 
    regs->ss = __USER32_DS;

set_fs(USER_DS);
-	if (regs->eflags & TF_MASK) {
-		if (current->ptrace & PT_PTRACED) {
-			ptrace_notify(SIGTRAP);
-		} else {
-			regs->eflags &= ~TF_MASK;
-		}
-	}
+    regs->eflags &= ~TF_MASK;
+    if (test_thread_flag(TIF_SINGLESTEP))
+        ptrace_notify(SIGTRAP);

#if DEBUG_SIG
    printk("SIG deliver (%s:%d): sp=%p pc=%p ra=%p\n",

wine ptrace trouble

[Jesse Allen]

On 10/25/05, Peter Beutner  wrote:
> Jesse Allen schrieb:
> > 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.
> > [..]
>
> thx for all the infos.
> I managed to track down the missing pieces in the kernel. The mentioned ptrace fix wasnt
> applied to the ia32 emulation code under x86_64. I already send a patch to lkml:
> http://lkml.org/lkml/2005/10/24/198
>
> A attach the patch again in case anyone wants to try it.

Yay!  Glad to help.