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

[David Fang]

Hi Ulrich,

>> 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;

Your suggestion worked to fix the addresses.
The only diff that remains between integrated/non-integrated assembly is:

--- hello-printf-as.otooldump   2013-05-23 12:49:14.000000000 -0700
+++ hello-printf.otooldump      2013-05-23 11:25:24.000000000 -0700
@@ -1,4 +1,4 @@
-hello-printf-as.o:
+hello-printf.o:
  Indirect symbols for (__TEXT,__picsymbolstub1) 2 entries
  address    index name
  0x00000140     2 ___swbuf
@@ -81,8 +81,8 @@
  000000ac       lwz     r31,0xfffc(r1)
  000000b0       mtspr   lr,r0
  000000b4       blr
-000000b8       nop
-000000bc       nop
+000000b8       .long 0x00000000
+000000bc       .long 0x00000000
  _main:
  000000c0       mfspr   r0,lr
  000000c4       stw     r31,0xfffc(r1)
@@ -94,7 +94,7 @@
  000000dc       li      r5,___sputc
  000000e0       stw     r5,0x58(r31)
  000000e4       stw     r3,0x54(r31)
-000000e8       addis   r2,r2,ha16(0x188-0xd8)
+000000e8       addis   r2,r2,ha16(0x188-0xd8+0xb00000)
  000000ec       stw     r4,0x50(r31)
  000000f0       addi    r2,r2,lo16(0x188-0xd8)
  000000f4       stw     r3,0x4c(r31)
<end-of-diff>

--- hello-printf-as.machodump   2013-05-23 12:49:14.000000000 -0700
+++ hello-printf.machodump      2013-05-23 11:25:24.000000000 -0700
@@ -1,5 +1,5 @@
  ('cputype', 18)
-('cpusubtype', 10)
+('cpusubtype', 0)
  ('filetype', 1)
  ('num_load_commands', 3)
  ('load_commands_size', 500)
<end-of-diff>

I'm not sure where the diff for the addis intruction comes from.
In the intermediate assembly, this come from:

...
L1$pb:
         mflr r2
         li r5, 0
         stw r5, 88(r31)
         stw r3, 84(r31)
         addis r2, r2, ha16(L_.str-L1$pb)
         stw r4, 80(r31)
         la r2, lo16(L_.str-L1$pb)(r2)
         stw r3, 76(r31)                 ; 4-byte Folded Spill
         mr r3, r2
...

Also, have you committed your 'diff-reloc-mcexpr' patch to trunk yet? or 
plan to do so?  If it's ready, in your opinion, it would make merging 
to branch easier for me.

Fang

-- 
David Fang
http://www.csl.cornell.edu/~fang/