On Fri, 2015-02-20 at 16:05 +0000, David Woodhouse wrote: > > It's been a while since I looked at this... but I think for the short > jumps we just emit the 8-bit version and there's a fixup which can go > back and re-emit the instruction in 32-bit mode if it finds it doesn't > fit? > > Do we just need to support a similar fixup for promoting 16-bit to > 32-bit relocations?
OK, the term I was looking for was 'relaxation'. Look in lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp for X86AsmBackend::relaxInstruction() and related methods. Observe that it will cope with 'relaxing' 8-bit PC-relative relocations to 32-bit PC-relative, but it doesn't cope with anything else. Your task, should you choose to accept it, is to make it cope with other forms of relaxation where necessary. Note that the existing cases end up emitting a new instruction with a *new* opcode. In your case it won't be doing that. It's the *same* opcode, but you'll have to set a flag to tell the emitter to use the 32-bit addressing mode (for data and/or addr as appropriate) this time. And while you're doing that, you should note that that's the *same* flag that'll be needed to support explicit addr32/data32 prefixes in the asm source. So you might as well support those too. I might suggest doing them *first*, in fact. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
