Re: CONFIG_HAVE_ARCH_TRACEHOOK and you

2008-09-12 Thread Christoph Hellwig
On Thu, Sep 11, 2008 at 07:57:33PM -0700, Roland McGrath wrote: 3. arch_ptrace() * You must define arch_ptrace() and not #define __ARCH_SYS_PTRACE. __ARCH_SYS_PTRACE is already gone :) 4. compat_arch_ptrace() * If your arch uses CONFIG_COMPAT, you must

Re: CONFIG_HAVE_ARCH_TRACEHOOK and you

2008-09-12 Thread Paul Mundt
On Thu, Sep 11, 2008 at 07:57:33PM -0700, Roland McGrath wrote: The comment in arch/Kconfig lists the items: # task_pt_regs() in asm/processor.h or asm/ptrace.h # arch_has_single_step() if there is hardware single-step support # arch_has_block_step() if there is

Re: CONFIG_HAVE_ARCH_TRACEHOOK and you

2008-09-12 Thread Russell King
Okay, let's comment on each bit separately. Regsets --- These don't appear to be a problem for ARM, and turn out to be relatively clean. The only thing I did do was invent some alternative simpler helper functions rather than using the user_regset_copy* functions (to avoid taking the

Re: CONFIG_HAVE_ARCH_TRACEHOOK and you

2008-09-12 Thread Roland McGrath
clean. The only thing I did do was invent some alternative simpler helper functions rather than using the user_regset_copy* functions (to avoid taking the address of function arguments, which needlessly forces them onto the stack.) Ideally those would get inlined so that doesn't happen.

Re: CONFIG_HAVE_ARCH_TRACEHOOK and you

2008-09-12 Thread David Miller
From: Roland McGrath [EMAIL PROTECTED] Date: Fri, 12 Sep 2008 15:31:56 -0700 (PDT) means sparc ends up allocating 38 * sizeof(u32) * sizeof(u32), and sparc64 ends up with 36 * sizeof(u64) * sizeof(u64), which must surely be wrong? Yup! Sure looks like Dave skipped the step where it says

Re: CONFIG_HAVE_ARCH_TRACEHOOK and you

2008-09-12 Thread Roland McGrath
It was allocating too much memory, which is harmless. Didn't it also write NT_PRFPREG notes of the wrong size? Thanks, Roland