Re: Regression in ptrace (Wine) starting with 2.6.33-rc1

[Michael Stefaniuc <mstefani@redhat.com>]

On 02/14/2010 09:41 PM, Frederic Weisbecker wrote:
> On Sun, Feb 14, 2010 at 09:13:06PM +0100, Michael Stefaniuc wrote:
>> Although Wine will map address 0x0 for DOS programs that isn't the
>> reason for those tests. Wine has to support games that come with
>> pointless copy protection schemes that employ that technique.
> Ah, which kind of protection?
No clue as I'm not into games. But the wiki has a page for that 
http://wiki.winehq.org/CopyProtection


>> Cool, thanks!
>> Any chance to get that fix into 2.6.33?
> Yeah.
>
> Could you please test the following patch on top of
> 2.6.33-rc9 ?
It is an improvement as I don't get an -EINVAL now but the data in DR7
is not what was written there and the test fails with:
exception.c:612: Test failed: failed to set debugregister 7 to 0x155, 
got 2aa

The corresponding ptrace calls for that test are:
ptrace(PTRACE_ATTACH, 3368, 0, 0)       = 0
ptrace(PTRACE_POKEUSER, 3368, offsetof(struct user, i387) + 28, 
0x42424242) = 0
ptrace(PTRACE_POKEUSER, 3368, offsetof(struct user, i387) + 32, 0) = 0
ptrace(PTRACE_POKEUSER, 3368, offsetof(struct user, i387) + 36, 0) = 0
ptrace(PTRACE_POKEUSER, 3368, offsetof(struct user, i387) + 40, 0) = 0
ptrace(PTRACE_POKEUSER, 3368, offsetof(struct user, i387) + 52, 0) = 0
ptrace(PTRACE_POKEUSER, 3368, offsetof(struct user, i387) + 56, 0x155) = 0
ptrace(PTRACE_DETACH, 3368, 0x1, SIG_0) = 0
ptrace(PTRACE_ATTACH, 3368, 0, 0)       = 0
ptrace(PTRACE_PEEKUSER, 3368, offsetof(struct user, i387) + 28, 
[0xfffffffc42424242]) = 0
ptrace(PTRACE_PEEKUSER, 3368, offsetof(struct user, i387) + 32, 
[0xfffffffd00000000]) = 0
ptrace(PTRACE_PEEKUSER, 3368, offsetof(struct user, i387) + 36, 
[0xfffffffe00000000]) = 0
ptrace(PTRACE_PEEKUSER, 3368, offsetof(struct user, i387) + 40, 
[0xffffffff00000000]) = 0
ptrace(PTRACE_PEEKUSER, 3368, offsetof(struct user, i387) + 52, 
[0x200000000]) = 0
ptrace(PTRACE_PEEKUSER, 3368, offsetof(struct user, i387) + 56, 
[0x3000002aa]) = 0
ptrace(PTRACE_DETACH, 3368, 0x1, SIG_0) = 0

> I'm trying to build wine but it fails because my libx11 is
> incorrect for the linking (probably because I don't have a x86-32
> version of libx11.so):
The easiest to bootstrap the build environment is to use the package
management of the distribution, e.g. yum-builddep wine on Fedora.  But
there are also howto's for other distributions on
http://wiki.winehq.org/WineOn64bit

> diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
> index 05d5fec..bb6006e 100644
> --- a/arch/x86/kernel/hw_breakpoint.c
> +++ b/arch/x86/kernel/hw_breakpoint.c
> @@ -212,25 +212,6 @@ static int arch_check_va_in_kernelspace(unsigned long va, u8 hbp_len)
>   	return (va>= TASK_SIZE)&&  ((va + len - 1)>= TASK_SIZE);
>   }
>
> -/*
> - * Store a breakpoint's encoded address, length, and type.
> - */
> -static int arch_store_info(struct perf_event *bp)
> -{
> -	struct arch_hw_breakpoint *info = counter_arch_bp(bp);
> -	/*
> -	 * For kernel-addresses, either the address or symbol name can be
> -	 * specified.
> -	 */
> -	if (info->name)
> -		info->address = (unsigned long)
> -				kallsyms_lookup_name(info->name);
> -	if (info->address)
> -		return 0;
> -
> -	return -EINVAL;
> -}
> -
>   int arch_bp_generic_fields(int x86_len, int x86_type,
>   			   int *gen_len, int *gen_type)
>   {
> @@ -362,10 +343,13 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp,
>   		return ret;
>   	}
>
> -	ret = arch_store_info(bp);
> -
> -	if (ret<  0)
> -		return ret;
> +	/*
> +	 * For kernel-addresses, either the address or symbol name can be
> +	 * specified.
> +	 */
> +	if (info->name)
> +		info->address = (unsigned long)
> +				kallsyms_lookup_name(info->name);
>   	/*
>   	 * Check that the low-order bits of the address are appropriate
>   	 * for the alignment implied by len.
>
>
>
>> I cannot test that as the corresponding test is directly affected by
>> this ABI change.
>
>
> Sure, let's fix the first problem to begin.
That regression isn't there anymore; I had seen it when the regression
search brought me to 66cb591. Now all other tests in ntdll/exception.c
pass just fine.

thanks
bye
	michael