On Thu, Feb 20, 2014 at 3:27 PM, H. Peter Anvin <h...@zytor.com> wrote:
>
> Another option is to say "don't do that then", and weed out the current
> uses of "m" and instead force the pointer in question explicitly into a
> register.
Passing addresses in registers is usually a *horrible* thing for the
kernel, because most of the time they are actually offsets within some
structure, and the address is almost invariably of the type
"offset(%register)". Which means that if you have to pass it as a pure
register, you are now (a) wasting a register and (b) adding an extra
"lea" or similar instruction just to do so.
Sadly, there is no good constraint for something like that. There's
"o" for "offsetable", but that is actually perfectly fine with a
PC-relative thing.
My preferred solution would be to (a) just say that it cannot be done
for replacement instructions (but is ok for the original
non-replacement one) and (b) perhaps have some build-time check of
just the replacement tables.
So then we'd at least get a build-time failure, and any users could be
taught that they have to use some obfuscation macro - I know we have
them, I can't recall their name, we've used them for the percpu stuff
- to force the address to be in a register rather than to be
%rip-relative.
Does that sound doable at all?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
