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

[Ulrich Weigand]

David Fang <fang at csl.cornell.edu> wrote on 21.05.2013 21:57:52:

>     With this change, I'm having a little trouble merging/resolving to
> the poewrpc-darwin8 branch, which implements PPCMachObjectWriter.cpp.
>
> https://github.com/fangism/llvm/blob/powerpc-darwin8/lib/Target/
> PowerPC/MCTargetDesc/PPCMachObjectWriter.cpp
>
> I have a function that translates like so:
> static
> unsigned
> getRelocType(
>          const MCValue &Target,
>          const MCFixupKind FixupKind,
>          const bool IsPCRel) {
> ...
>      case PPC::fixup_ppc_lo16:
>        Type = macho::RIT_PPC_LO16;
>        break;
>      case PPC::fixup_ppc_ha16:
>        Type = macho::RIT_PPC_HA16;
>        break;
> ...
> }
[snip]
> With the merge to PPC::fixup_ppc_half16, I don't have a direct way to
> translate to the Mach-O values.
> The Mach-O enums can't be changed, but they need to somehow distinguish
> between HA16 and LO16.
> How would you advise I resolve this?

Hi David,

the proper fix for this is the same as for the ELF target,
you'll need to look at the symbol properties to determine
whether hi or lo part of the address are requested; looking
at the instruction (which is what the old FixupKind did)
isn't really correct in general.

PPCELFObjectWriter now handles it like this:

  MCSymbolRefExpr::VariantKind Modifier = Target.isAbsolute() ?
    MCSymbolRefExpr::VK_None : Target.getSymA()->getKind();
[...]
    case PPC::fixup_ppc_half16:
      switch (Modifier) {
      case MCSymbolRefExpr::VK_PPC_GAS_HA16:
      case MCSymbolRefExpr::VK_PPC_DARWIN_HA16:
        Type = ELF::R_PPC_ADDR16_HA;
        break;
      case MCSymbolRefExpr::VK_PPC_GAS_LO16:
      case MCSymbolRefExpr::VK_PPC_DARWIN_LO16:
        Type = ELF::R_PPC_ADDR16_LO;
        break;

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.  The
ARM back-end does this by checking the target expression
in the code emitter, and then using different fixup
types after all.  Huh.

I'll see if can come up with a solution that makes
sense for both ELF and Darwin objects ...

Bye,
Ulrich