• Quentin Barnes's avatar
    ARM kprobes: instruction single-stepping support · 35aa1df4
    Quentin Barnes authored
    This is the code implementing instruction single-stepping for kprobes
    on ARM.
    
    To get around the limitation of no Next-PC and no hardware single-
    stepping, all kprobe'd instructions are split into three camps:
    simulation, emulation, and rejected. "Simulated" instructions are
    those instructions which behavior is reproduced by straight C code.
    "Emulated" instructions are ones that are copied, slightly altered
    and executed directly in the instruction slot to reproduce their
    behavior.  "Rejected" instructions are ones that could be simulated,
    but work hasn't been put into simulating them. These instructions
    should be very rare, if not unencountered, in the kernel. If ever
    needed, code could be added to simulate them.
    
    One might wonder why this and the ptrace singlestep facility are not
    sharing some code.  Both approaches are fundamentally different because
    the ptrace code regains control after the stepped instruction by installing
    a breakpoint after the instruction itself, and possibly at the location
    where the instruction might be branching to, instead of simulating or
    emulating the target instruction.
    
    The ptrace approach isn't suitable for kprobes because the breakpoints
    would have to be moved back, and the icache flushed, everytime the
    probe is hit to let normal code execution resume, which would have a
    significant performance impact. It is also racy on SMP since another
    CPU could, with the right timing, sail through the probe point without
    being caught.  Because ptrace single-stepping always result in a
    different process to be scheduled, the concern for performance is much
    less significant.
    
    On the other hand, the kprobes approach isn't (currently) suitable for
    ptrace because it has no provision for proper user space memory
    protection and translation, and even if that was implemented, the gain
    wouldn't be worth the added complexity in the ptrace path compared to
    the current approach.
    
    So, until kprobes does support user space, both kprobes and ptrace are
    best kept independent and separate.
    Signed-off-by: default avatarQuentin Barnes <qbarnes@gmail.com>
    Signed-off-by: default avatarAbhishek Sagar <sagar.abhishek@gmail.com>
    Signed-off-by: default avatarNicolas Pitre <nico@marvell.com>
    35aa1df4
kprobes.h 1.1 KB