[llvm] [JITLink][XCOFF] Setup initial build support for XCOFF (PR #127266)

[Hubert Tong via llvm-commits]

================
@@ -227,6 +229,47 @@ getCOFFObjectFileSymbolInfo(ExecutionSession &ES,
   return I;
 }
 
+Expected<MaterializationUnit::Interface>
+getXCOFFObjectFileSymbolInfo(ExecutionSession &ES,
+                             const object::ObjectFile &Obj) {
+
+  MaterializationUnit::Interface I;
+
+  for (auto &Sym : Obj.symbols()) {
+    Expected<uint32_t> SymFlagsOrErr = Sym.getFlags();
+    if (!SymFlagsOrErr)
+      return SymFlagsOrErr.takeError();
+    uint32_t Flags = *SymFlagsOrErr;
+
+    // Skip undefined, non global and ST_File
+    if (Flags & object::SymbolRef::SF_Undefined)
+      continue;
+    if (!(Flags & object::SymbolRef::SF_Global))
+      continue;
+
+    auto SymbolType = Sym.getType();
+    if (!SymbolType)
+      return SymbolType.takeError();
+
+    if (*SymbolType == object::SymbolRef::ST_File)
+      continue;
+
+    auto Name = Sym.getName();
+    if (!Name)
+      return Name.takeError();
+    auto SymFlags = JITSymbolFlags::fromObjectSymbol(Sym);
+    if (!SymFlags)
+      return SymFlags.takeError();
+
+    // TODO: Global symbols should have default visibility for now
+    *SymFlags |= JITSymbolFlags::Exported;
----------------
hubert-reinterpretcast wrote:

I agree that changing `XCOFFObjectFile::getSymbolFlags` should be separate from the current patch.

With respect to that patch (but off-topic for the current one), I want to emphasize that the `getSymbolFlags` implementation should ideally consult the loader symbol table when provided with an object that contains one. I do not know whether or not that has a practical effect for BOLT or other use cases.

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