[PATCH] D72027: [XCOFF][AIX] Support basic relocation type on AIX

[Jason Liu via Phabricator via llvm-commits]

jasonliu marked 2 inline comments as done.
jasonliu added inline comments.


================
Comment at: llvm/lib/MC/XCOFFObjectWriter.cpp:409
+    // plus any constant value that we might get.
+    FixedValue = SectionMap[SymASec]->Address +
+                 (SymA.isDefined() ? Layout.getSymbolOffset(SymA) : 0) +
----------------
jasonliu wrote:
> hubert.reinterpretcast wrote:
> > Is `SectionMap[SymASec]->Address` a fancy way of saying `0` for undefined symbols? If so, can we move it into the ternary expression?
> SectionMap[SymASec]->Address is not just for undefined symbols. If SymA is a label inside of csect, we need to get (the csect address + the symbol offset) to get the exact address of that label. 
Had offline discussion on this, and I will change the code to this as suggested.

```
FixedValue = (SymA.isDefined() ? SectionMap[SymASec]->Address + Layout.getSymbolOffset(SymA) 
                                                       : 0) + Target.getConstant();
```



================
Comment at: llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll:85
+; RELOC-NEXT:     Symbol: globalA (18)
+; RELOC-NEXT:     IsSigned: No
+; RELOC-NEXT:     FixupBitValue: 0
----------------
daltenty wrote:
> jasonliu wrote:
> > daltenty wrote:
> > > For the R_TOC relocation, shouldn't this be signed as this is a displacement?
> > The relocation reference for toc entry should always be unsigned, because it is relative to the TOC anchor, and TOC entry has to come after TOC anchor. 
> This does not appear to be the case generally. While we may generate them at a strictly positive offset in the object file 
> (possible more than can fit in the available displacement), the linker will combine and reorder them into a valid order.
> 
> Thus if there are more than 8192 TOC entries (in 32-bit mode), the linker will place TC entries above the anchor and generate the appropriately negatively signed displacement. 
> 
> XLC also thus appears to generate these relocations as signed.
You are right.
There are some offline discussion going on with @daltenty and also people from AIX OS team. I will try to summarize them here and also put into the comments.
1. The linker could move TC entries above TOC anchor during linking. So they could have a negative offset. 
2. However, assembler generates unsigned bit for this TC entry relocation.
3. Stephen from AIX OS says the sign bit of relocation is mostly ignored by the link-editor. What's important is the behavior of the hardware instruction. 

Based on that, here's what I'm planning to do in this patch:
1. Since the signness does not matter most of the time, let's just follow what assembler's behavior and use the IsPCRel to determine if it is signed or not. 
2. For this patch, let's disallow the overflow in the compiler. Report fatal_error when positive range runs out. 




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72027/new/

https://reviews.llvm.org/D72027