Re: [patch v3 19/36] Hexagon: Add ptrace support

[Jonas Bonn]

On 9 September 2011 03:09, Richard Kuo <rkuo@xxxxxxxxxxxxxx> wrote:
> +long arch_ptrace(struct task_struct *child, long request,
> + Â Â Â Â Â Â Â Âunsigned long addr, unsigned long data)
> +{
> + Â Â Â void __user *udata = (void __user *) data;
> +
> + Â Â Â switch (request) {
> + Â Â Â case PTRACE_POKETEXT: Â /* write the word at location addr. */
> + Â Â Â case PTRACE_POKEDATA:
> + Â Â Â Â Â Â Â return generic_ptrace_pokedata(child, addr, data);
> + Â Â Â case PTRACE_POKEUSR: Â Â/* write register specified by addr. */
> + Â Â Â Â Â Â Â return ptrace_pokeusr(child, addr, data);
> + Â Â Â case PTRACE_GETREGS:
> + Â Â Â Â Â Â Â return copy_regset_to_user(child, &hexagon_user_view,
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ÂREGSET_GPR, 0,
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âsizeof(struct user_regs_struct),
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âudata);
> + Â Â Â case PTRACE_SETREGS:
> + Â Â Â Â Â Â Â return copy_regset_from_user(child, &hexagon_user_view,
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ÂREGSET_GPR, 0,
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âsizeof(struct user_regs_struct),
> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âudata);
> + Â Â Â default:
> + Â Â Â Â Â Â Â return ptrace_request(child, request, addr, data);
> + Â Â Â }
> +
> + Â Â Â return 0;
> +}
>

I think that... other than for compatibility with legacy userspace
code, you shouldn't need any of these cases other than the 'default'.

PTRACE_GETREGS is replaced by PTRACE_GETREGSET and this is handled in
generic code.  POKETEXT, POKEDATA are handled in the generic code.
POKEUSR can also be done via the SETREGSET mechanism.

That said, I don't think gdbserver has been updated to use
GETREGSET/SETREGSET.  This is a bit like the uClibc/glibc issue,
though... somebody just needs to do the work to make userspace work
with the new, "clean" kernel interface.

Given all that, you shouldn't need to export pt_regs to userspace
either.  You already have a user_regs_struct which is userspace's view
of the process registers.  For OpenRISC we made pt_regs a kernel
private structure, giving us the freedom to change the stack layout of
the registers in the future while providing a stable view for
userspace.  I would suggest doing the same here.

If you do decide to make pt_regs private, you'll need to change your
struct sigcontext to use user_regs_struct, as well.

/Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/