Messages in this thread Patch in this message | | | Date | Mon, 15 Feb 2010 00:05:16 +0100 | From | Michael Stefaniuc <> | Subject | Re: Regression in ptrace (Wine) starting with 2.6.33-rc1 |
| |
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
| |