lkml.org 
[lkml]   [2010]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
    > Re: rewriting instructions that use rip-relative addressing.  We do that
    > now. See handle_riprel_insn() in patch #2. (As far as we can tell, it
    > works, but we'd appreciate your review of it.)

    Yes, but how do you get within 2GB of it? Add lots of holes
    in the address space?

    > The instruction decoder is used only during instruction analysis, while
    > registering the probe -- i.e., in kernel space.

    Registering the user probe? That means if there's a buffer overflow
    in there it would be exploitable.

    > >
    > > In general the trend has been also to make traps faster in the CPU, make
    > > sure you're not optimizing for some old CPU here.
    >
    > I won't argue with that. What Avi seems to be proposing buys us a
    > speedup, but at the cost of increased complexity -- among other things,
    > splitting the instrumentation code between user space (in the "XOL" area
    > -- which would then be used for much more than XOL instruction slots)

    You can't have a single XOL area, at least not if you want to support
    shared libraries on 64bit & rip relative.

    > and kernel space. The splitting would presumably be handled by
    > higher-level code -- SystemTap, perf, or whatever. It's a neat idea,
    > but it seems like a v2 kind of feature.

    I'm not sure it can even work, unless you severly limited the allowed
    instructions.

    -Andi

    --
    ak@linux.intel.com -- Speaking for myself only.


    \
     
     \ /
      Last update: 2010-01-20 21:01    [W:0.019 / U:0.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site