Re: [PATCH 1/1] x86: fix text_poke

[H. Peter Anvin]

David Miller wrote:
> From: "H. Peter Anvin" <hpa@xxxxxxxxx>
> Date: Fri, 25 Apr 2008 13:41:00 -0700
>
> > Yes, that should work.  It's still ugly, and I have to say I find the 
> > complexity rather distasteful.  I am willing to be convinced it's worth 
> > it, but I would really like to see hard numbers.
>
> This stuff would have been a lot easier if it just worked with
> normal relocations generated by the assembler, and that would
> work in such a straightforward way on EVERY architecture.
>
> The immediate instance generators could just use macros that
> architectures define, which are given a range of legal values for the
> immediate, and the macro emits the inline asm sequence that can
> support an immediate value of that range.
>
> Then we do a half-link of the kernel, collect the unresolved
> relocations from generated by the immediate macros into a table which
> gets linked into the kernel, then resolve them in the final link all
> to zero or some defined initial value.
>
> Then it's just a matter of running through the relocation handling
> we already have for module loading when changing an immediate
> value.
>
> None of this crazy instruction parsing and branch following crap.
> I can't believe we're seriously considering this crud. :-/

That's already there, for all practical purposes.  The point of 
contention here is trying to go from immediate value rewriting to branch 
rewriting, which is probably the vast majority of all desired uses. 
However, branch rewriting affects the flow of control, and flow of 
control is inherently vital for gcc to understand.

I'm not inherently opposed to branch target rewriting, but I believe gcc 
really needs to be involved in the process.  On systems compiled with 
older compilers, we just won't use that feature -- similar to most other 
features introduced in a new compiler.

	-hpa


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