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

[David Fang]

Hi Ulrich,

>> >  Unfortunately, on Darwin, the VK_PPC_DARWIN_HA16/LO16
>> >  markers are currently not 100% correct, since in some
>> >  cases the back-end makes hard-coded assumptions on
>> >  where lo/ha markers are required.  If you recall my
>> >  patch you've been testing recently, this was intended to
>> >  address exactly this problem.  With the patch applied,
>> >  it should be possible to reliably check for the HA/LO
>> >  target-specific expressions.
>> > 
>> >  However, it seems we cannot in fact use the MCValue
>> >  object to represent target-specific flags resulting
>> >  from evaluation of target-specific expressions.
>>
>>  Looks like I was too pessimistic here; in fact, it now
>>  seems relatively straight-forward to do exactly that.
>>
>>  The attached patch is an updated version of the Darwin
>>  target-specific MCExpr patch, now including an
>>  EvaluateAsRelocatableImpl routine that processes
>>  HA/LO expressions.
>>
>>  With this patch applied, the solution for PPCMachObjectWriter
>>  outlined above (consult the VariantKind to distinguish
>>  between HA and LO relocations) should now work reliably.
>
> Thanks for the patch preview.
> Now my code (PPCMachObjectWriter.cpp) contains:
[snip]
> The rest is still compiling.
> I'll try a few test programs after the build finishes.
>
>>  (Note that the patch merges VK_PPC_GAS_HA16 and
>>  VK_PPC_DARWIN_HA16 into a single VK_PPC_ADDR16_HA and
>>  likewise for LO, so you'll have to adapt the example.)
>>
>>  Can you try and see if that works for you?  If so,
>>  I can commit the patch to the repository to make
>>  merging into your branch easier ...

llvm/clang finished building, and I retried an old hello-world test:

#include <stdio.h>
int
main(int argc, char* argv[]) {
         printf("Hello, world!\n");
         return 0;
}

I'm compiling with:
-fno-common -DPIC -femit-all-decls
(using integrated assembler)

The linker gave a relocation entry error on hello-printf.o,
so I saved the intermediate assembly with -S as hello-printf.s,
and assembled this using the system assembler to hello-printf-as.o.
I then compared the object dumps of the .o files (as vs. clang).

--- hello-printf-as.otooldump   2013-05-22 17:52:23.000000000 -0700
+++ hello-printf.otooldump      2013-05-22 17:36:31.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
@@ -14,20 +14,20 @@
  Relocation information (__TEXT,__text) 6 entries
  address  pcrel length extern type    scattered symbolnum/value
  00000104 True  long   False  BR24    False     3 
(__TEXT,__picsymbolstub1)
-000000f0 False long   n/a    LO16DIF True      0x00000188
+000000f2 False long   n/a    LO16DIF True      0x00000188
           False long   n/a    PAIR    True      0x000000d8 other_half = 
0x0000
-000000e8 False long   n/a    HA16DIF True      0x00000188
+000000ea False long   n/a    HA16DIF True      0x00000188
           False long   n/a    PAIR    True      0x000000d8 other_half = 
0x00b0
  00000098 True  long   False  BR24    False     3 
(__TEXT,__picsymbolstub1)
  Relocation information (__TEXT,__picsymbolstub1) 8 entries
  address  pcrel length extern type    scattered symbolnum/value
-00000034 False long   n/a    LO16DIF True      0x00000184
+00000036 False long   n/a    LO16DIF True      0x00000184
           False long   n/a    PAIR    True      0x00000168 other_half = 
0x0000
-0000002c False long   n/a    HA16DIF True      0x00000184
+0000002e False long   n/a    HA16DIF True      0x00000184
           False long   n/a    PAIR    True      0x00000168 other_half = 
0x001c
-00000014 False long   n/a    LO16DIF True      0x00000180
+00000016 False long   n/a    LO16DIF True      0x00000180
           False long   n/a    PAIR    True      0x00000148 other_half = 
0x0000
-0000000c False long   n/a    HA16DIF True      0x00000180
+0000000e False long   n/a    HA16DIF True      0x00000180
           False long   n/a    PAIR    True      0x00000148 other_half = 
0x0038
  Relocation information (__DATA,__la_symbol_ptr) 2 entries
  address  pcrel length extern type    scattered symbolnum/value


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?

Fang


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