[lkml]   [2011]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: test-case (Was: [PATCH 12/X] uprobes: x86: introduce abort_xol())
    On 10/25, Srikar Dronamraju wrote:
    > >
    > > static inline void *uc_ip(struct ucontext *ctxt)
    > > {
    > > return (void*)ctxt->uc_mcontext.gregs[16];
    > > }
    > > ...
    > >
    > I have tested this on both x86_32 and x86_64 and can confirm that the
    > behaviour is same with or without uprobes placed at that instruction.
    > This is on the uprobes code with your changes.

    Great, thanks.

    > However on x86_32; the output is different from x86_64.
    > On x86_32 (I have additionally printed the uc_ip and fault_insn.
    > SIGSEGV! ip=0x10246 addr=0x12345678
    > ERR!! wrong ip uc_ip(ctxt) = 10246 fault_insn = 804856c

    Yep. uc_ip() is not correct on x86_32. Sorry, I forgot to mention this.

    I was really surprised when I wrote this test. I simply can't understand
    how can I play with ucontext in the user-space. I guess uc_ip() should use
    REG_EIP instead of 16, but I wasn't able to compile it even if I added
    __USE_GNU. It would be even better to use sigcontext instead of the ugly
    mcontext_t, but this looks "impossible". The kernel is much simpler ;)

    > I still trying to dig up what uc_ip is and why its different on x86_32.

    See above. I guess it needs ctxt->uc_mcontext.gregs[14]. Or REG_EIP.

    uc_ip() simply reads sigcontext->ip passed by setup_sigcontext().

    > Also I was thinking on your suggestion of making abort_xol a weak
    > function. In which case we could have architecture independent function
    > in kernel/uprobes.c which is just a wrapper for set_instruction_pointer.
    > void __weak abort_xol(struct pt_regs *regs, struct uprobe_task *utask)
    > {
    > set_instruction_pointer(regs, utask->vaddr);
    > }
    > where it would called from uprobe_notify_resume() as
    > abort_xol(regs, utask);
    > If other archs would want to do something else, they could override
    > abort_xol definition.

    I didn't suggest this ;) But looks reasonable to me. And afaics x86_32
    can use this arch-independent function.


     \ /
      Last update: 2011-10-25 17:57    [W:0.022 / U:7.764 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site