[clang-tools-extra] [llvm] [clang] [XCOFF][obj2yaml] support parsing auxiliary symbols for XCOFF (PR #70642)

[via cfe-commits]

================
@@ -106,6 +126,210 @@ Error XCOFFDumper::dumpSections(ArrayRef<Shdr> Sections) {
   return Error::success();
 }
 
+Error XCOFFDumper::dumpFileAuxSym(XCOFFYAML::Symbol &Sym,
+                                  const XCOFFSymbolRef &SymbolEntRef) {
+  for (uint8_t I = 1; I <= Sym.NumberOfAuxEntries; ++I) {
+    uintptr_t AuxAddress = XCOFFObjectFile::getAdvancedSymbolEntryAddress(
+        SymbolEntRef.getEntryAddress(), I);
+    const XCOFFFileAuxEnt *FileAuxEntPtr =
+        getAuxEntPtr<XCOFFFileAuxEnt>(AuxAddress);
+    auto FileNameOrError = Obj.getCFileName(FileAuxEntPtr);
+    if (!FileNameOrError)
+      return FileNameOrError.takeError();
+
+    XCOFFYAML::FileAuxEnt FileAuxSym;
+    FileAuxSym.FileNameOrString = FileNameOrError.get();
+    FileAuxSym.FileStringType = FileAuxEntPtr->Type;
+    Sym.AuxEntries.push_back(
----------------
EsmeYi wrote:

If I understand you correctly, I think currently we have print the aux type in the yaml file regardless of whether it is 32-bit or 64-bit. There is a constructor in each aux symbol struct, like `FileAuxEnt():AuxSymbolEnt(AuxSymbolType::AUX_FILE) {}`, and we can verify this in the test file llvm/test/tools/obj2yaml/XCOFF/aux-symbols.yaml

( Although auxiliary symbol entries in XCOFF32 do not really have the x_auxtype field, it's no harm to print the info in yaml and it's helpful when transforming yaml to object.


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