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-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
