On Sun, Feb 14, 2010 at 09:13:06PM +0100, Michael Stefaniuc wrote:No clue as I'm not into games. But the wiki has a page for that http://wiki.winehq.org/CopyProtectionAlthough Wine will map address 0x0 for DOS programs that isn't theAh, which kind of protection?
reason for those tests. Wine has to support games that come with
pointless copy protection schemes that employ that technique.
It is an improvement as I don't get an -EINVAL now but the data in DR7Cool, thanks!Yeah.
Any chance to get that fix into 2.6.33?
Could you please test the following patch on top of
2.6.33-rc9 ?
I'm trying to build wine but it fails because my libx11 isThe easiest to bootstrap the build environment is to use the package
incorrect for the linking (probably because I don't have a x86-32
version of libx11.so):
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.cThat regression isn't there anymore; I had seen it when the regression
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.