"m" constraints, jumps, and alternatives

["H. Peter Anvin" <hpa@zytor.com>]

Hi all,

The alternatives mechanism suffers from problems whenever there are
PC-relative items in the instruction stream.  We currently have a hack
in the alternatives mechanism where we detect the opcode of a call or
jmp instruction and adjust the offset, but that only works if the
replacement code consists solely of a call or jmp.

Well, when there are "m" contraints, we could end up with PC-relative
offsets if someone were to point the function in question at a global
variable on 64 bits.  This is much harder to decode at runtime; doing so
would require pretty much a full x86 decoder (which we do have one in
the kernel now, but it would be pretty slow I would think.)

I talked with H.J. about this, and one way to do this would be to do
post-linkage fixup of the alternatives section.  This does, however,
would seem to not work easily with kernel modules, as the kernel module
is left pre-link.  We could, of course, do equivalent fixup in the
kernel at module insertion time, since the module will include the
relocations.

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.

What do you guys think?

	-hpa