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

[via llvm-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(
----------------
diggerlin 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.

My understand we should print out the fields as it is in the object file.  what is James' opinion ? @jh7370 


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