[llvm] [JITLink] [GOFF] Initial support for GOFF (PR #224683)

[Shimin Cui via llvm-commits]

================
@@ -87,6 +87,14 @@ enum EdgeKind_systemz : Edge::Kind {
   ///
   Pointer8,
 
+  /// GOFF: Absolute add (field += value) for length 64 and 32.
+  Pointer64Add,
+  Pointer32Add,
+
+  /// GOFF: Absolute subtract (field -= value) for length 64 and 32.
+  Pointer64Sub,
+  Pointer32Sub,
----------------
scui-ibm wrote:

> Can you explain a little more about how these edges are intended to work?
> 
> As written these look like regular `Pointer32` / `Pointer64`, only with the addend encoded in the content. If that's all they are I'd say read the content in the LinkGraph builder and use it to build a regular `Pointer32` / `Pointer64` that writes back at mixup time.
> 
> From a glance at the GOFF docs though it sounds like these are part of a composable relocation design? If that's the case this will require some more thought -- we mostly happen to preserve `Edge` order today, but it's not part of JITLInk's contract, and something like this would depend on it ether becoming contract, or us inventing a new and more flexible `Edge` design.

In GOFF, the addend may not encoded in the content of the object.  Complex relocations at the same offset can be encoded as a sequence of consecutive items of RLD records. For example, you can have two relocation entries at the same location with GOFF::RLD_FS_Store and GOFF::RLD_FS_Fetch actions , and the order of GOFF::RLD_FS_Store and GOFF::RLD_FS_Fetch of two RLD entries matters as GOFF::RLD_FS_Store is imply to overwrite the result. Therefore, for RLD entries sharing the same target address, we need match the physical order in the RLD stream of the GOFF object. 

With current implementation, the order is actually guaranteed for the same location relocation entries - a linear vector of relocation entries (see SmallVector<GOFFRelEntry, 256> RelEntries in GOFFObjectFile.h) is recorded when reading the object file and the JITLink edges are inserted in the same order in each JITLink block (see std::vector<Edge> Edges in JITLink.h) and extracted during relocation fixup.
 
For entries targeting different addresses of different sections, there is no order required for relocation fixup. The operations are orthogonal. We don’t need to worry about it.

https://github.com/llvm/llvm-project/pull/224683