lkml.org 
[lkml]   [2006]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Linux Kernel Markers

    Martin Bligh wrote:
    > be that many? Still doesn't fix the problem Matieu just pointed
    > out though. Humpf.

    There's one possibility if we're willing to insert a placeholder
    at function entry that allows to essentially do what Andrew
    suggests without much impact. Specifically, if you need a 5-byte
    operation to jump to the alternate instrumented function, you
    can then do something like:
    1- At build time insert 5-byte unconditional jump to instruction
    right after placeholder.
    2- At runtime for diverting flow:
    - Replace first byte with int3 (atomically)
    - Replace next 4 bytes with instrumented function destination
    - Replace first byte
    3- At runtime for returning flow:
    - Do #2 but for the original placeholder jump.

    There's not race condition here or fear of interrupt return in
    the middle of anything, or any need to stop the kernel from
    operating and the likes, or even dependency on kprobes or need
    for dprobes, at least in as far as I can see -- so this should
    be trivial on m68k ;). The price to pay is an additional
    unconditional jump at all times, which should be optimized at
    runtime by the CPU. Benchmarks could help show the real impact,
    but as Ingo said, these things should be minimal.

    In sum, this would work for function pointers and wouldn't
    require having to walk the code in search of instances of
    "call foo" to replace.

    Just a thought.

    Karim

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

    \
     
     \ /
      Last update: 2006-09-19 22:57    [W:3.564 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site