Hello Harvey,
A similar idea was already nack-ed by Ananth.
http://sources.redhat.com/ml/systemtap/2007-q4/msg00468.html
And I agree his thought.
Especially, "riprel" does not exist on x86_32, so fix_riprel()
is meaningless on it.
Thus, I think it would better be ifdef'd in call-site.
Harvey Harrison wrote:
> Move #ifdef around function definiton into the function and
> unconditionally return on X86_32. Saves an ifdef from the
> one callsite.
>
> Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
> ---
> Ingo, Masami, final leftovers from some unsent kprobes unification work.
>
> Net reduction of one #ifdef section.
>
> arch/x86/kernel/kprobes.c | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
> index b1804e4..1ac532e 100644
> --- a/arch/x86/kernel/kprobes.c
> +++ b/arch/x86/kernel/kprobes.c
> @@ -263,15 +263,16 @@ static int __kprobes is_IF_modifier(kprobe_opcode_t
> *insn)
> return 0;
> }
>
> -#ifdef CONFIG_X86_64
> /*
> * Adjust the displacement if the instruction uses the %rip-relative
> * addressing mode.
> * If it does, Return the address of the 32-bit displacement word.
> * If not, return null.
> + * Only applicable to X86_64
> */
> static void __kprobes fix_riprel(struct kprobe *p)
> {
> +#ifdef CONFIG_X86_64
> u8 *insn = p->ainsn.insn;
> s64 disp;
> int need_modrm;
> @@ -335,15 +336,17 @@ static void __kprobes fix_riprel(struct kprobe *p)
> *(s32 *)insn = (s32) disp;
> }
> }
> -}
> +#else
> + return;
> #endif
> +}
>
> static void __kprobes arch_copy_kprobe(struct kprobe *p)
> {
> memcpy(p->ainsn.insn, p->addr, MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
> -#ifdef CONFIG_X86_64
> +
> fix_riprel(p);
> -#endif
> +
> if (can_boost(p->addr))
> p->ainsn.boostable = 0;
> else
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: [EMAIL PROTECTED], [EMAIL PROTECTED]
--
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/
