[llvm] [XCOFF][obj2yaml] support parsing auxiliary symbols for XCOFF (PR #70642)

[James Henderson via llvm-commits]

================
@@ -106,6 +111,79 @@ Error XCOFFDumper::dumpSections(ArrayRef<Shdr> Sections) {
   return Error::success();
 }
 
+static void
+dumpFileAuxSym(std::vector<std::unique_ptr<XCOFFYAML::AuxSymbolEnt>> &AuxEntTbl,
+               XCOFF::CFileStringType Type, StringRef FileStr) {
+  XCOFFYAML::FileAuxEnt FileAuxSym;
+  FileAuxSym.FileNameOrString = FileStr;
+  FileAuxSym.FileStringType = Type;
+  AuxEntTbl.push_back(std::make_unique<XCOFFYAML::FileAuxEnt>(FileAuxSym));
+}
+
+static void
+dumpStatAuxSym(std::vector<std::unique_ptr<XCOFFYAML::AuxSymbolEnt>> &AuxEntTbl,
+               const object::XCOFFSectAuxEntForStat &AuxEntPtr) {
+  XCOFFYAML::SectAuxEntForStat StatAuxSym;
+  StatAuxSym.SectionLength = AuxEntPtr.SectionLength;
+  StatAuxSym.NumberOfLineNum = AuxEntPtr.NumberOfLineNum;
+  StatAuxSym.NumberOfRelocEnt = AuxEntPtr.NumberOfRelocEnt;
+  AuxEntTbl.push_back(
----------------
jh7370 wrote:

I think the implementation of the constructors can be in the cpp, should you choose to go down that route. I think having constructors will likely make things cleaner, but you lose the POD nature of the objects. I've got no strong feeling on whether that is an issue or not, and leave it up to you two and other XCOFF stakeholders to agree on that (I don't think it needs to match COFF/ELF etc specifically).

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