[llvm] r182092 - [PowerPC] Merge/rename PPC fixup types

Ulrich Weigand Ulrich.Weigand at de.ibm.com
Thu May 23 01:48:29 PDT 2013


David Fang <fang at csl.cornell.edu> wrote on 23.05.2013 03:04:40:

> -000000f0 False long   n/a    LO16DIF True      0x00000188
> +000000f2 False long   n/a    LO16DIF True      0x00000188
[snip]
> The addresses seem to be off by 2 now, relative to the system assembler
> output.  I don't think that the patches in question would have affected
> this.  Are you aware of any other PPC back-end changes that would affect
> the relocation address calculations?

Yes, that was done by this patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130513/174527.html

Note that on ELF, the relocation *should* point to the second
half of the instruction, and the code used a (seemingly)
uncecessarily complex way of achieving this.

However, it looks like on Mach-O, the relocation actually does
have to point to the start of the instruction itself.  Hmm.

It would appear the simplest way to fix this now would be for
you to add something along those lines at the places where
FixupOffset is computed in RecordScatteredRelocation and
RecordPPCRelocation:

after:
  uint32_t FixupOffset = Layout.getFragmentOffset(Fragment)+Fixup.getOffset
();
add:

  // On Mach-O ppc_fixup_half16 relocations must refer to the
  // start of the instruction, not the second halfword
  if (Fixup.getKind() == PPC::fixup_ppc_half16)
    FixupOffset &= ~3;

Bye,
Ulrich




More information about the llvm-commits mailing list