Mathieu Desnoyers wrote:
Yup, good catch. I have not seen gcc removing this asm in my objdump however, by
I guess we cannot be sure. This MARK_SYM() is only useful for kprobe
insertion : I don't use it myself for the jump markup stuff. I don't know how
relevant it is for kprobes users for the symbol to be at a specific location,
as they don't know themself what data they are interested in and they simply
don't want to modify the instruction stream. I fact, if the asm volatile
modifies the instruction stream, it would be an unwanted side-effect :(
"asm volatile" isn't documented to do anything other than prevent the
asm from being removed altogether. It doesn't prevent it from being
moved elsewhere, and it doesn't imply any ordering dependency with the
code around it. So I don't think it will change the generated code, but
I also don't think it will be all that useful unless there's something
to actually make sure it's in a particular place - and that may change
codegen because it may force the compiler to not eliminate/reorder/move
the point at which you want the label.
Something like this might do it:
#define MARK_SYM(label) \
do { \
__label__ here; \
here: asm volatile(#label " = %0" : : "m" (*&&here)); \
} while(0)
This at least gives the compiler a C-level label to hang the asm from.
It doesn't matter :) You are absolutely right, they can get reordered, and the
fact is : we don't care. The function above sets the *target_mark_call before
the *target_mark_jump_over, so that the function pointer is set up before the
jump can call it. But imagine the inverse : the will be able to the function
call before the function call handler is set up. It really doesn't matter
because the function pointer is always pointing to a valid function : either the
"empty" default function or the inserted one.
Does the local indirect jump really help? Wouldn't you do just as well
with the call? It's a jump out of line, but if it points to the null
function, it's likely to be in cache, and reducing the number of
indirect targets within a few instructions will help the CPU keep its
branch target prediction in order (modern Intel chips don't like having
too many indirect jumps within a cache line, for example).
It's a pity you can't make these all direct jumps; I guess patching the
instruction stream on an SMP system on the fly is too tricky...
(Though on x86 you could do something like make the default case 5 bytes
of nops. Then to patch it, you could patch in an int3 on the first
byte, put the relative address in the other 4 bytes, then patch the int3
back to the call/jump. The int3 handler would look to see if the fault
address is a kernel hook point, and if so, spin waiting for the *eip to
go to a call/jump, then resume the instruction.)
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
