================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
