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

[James Henderson 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(
----------------
jh7370 wrote:

Sorry, I'm not really sure I follow the conversation, as it is too much in the file format details. Some general comments:
1) We need enough info in the YAML produced by obj2yaml for yaml2obj to be able to create an identical object as was passed to obj2yaml.
2) This means we can potentially omit fields from the YAML dump if they have a value matching the default value yaml2obj would use if the field is omitted.
3) The less data we have in the YAML, the better, as long as the first point is conformed to. This is because it'll be easier to read, and if somebody is using obj2yaml to generate the YAML that will be used as the input in a test case, it is minimal and has no redundant information.

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