llvvm-readobj support display symbol table of loader section of xcoff object file.
https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-object-file-format#XCOFF__vra3i31ejbau
Differential D135887
[XCOFF] llvm-readobj support display symbol table of loader section of xcoff object file. DiggerLin on Oct 13 2022, 8:35 AM. Authored by
Details llvvm-readobj support display symbol table of loader section of xcoff object file. https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-object-file-format#XCOFF__vra3i31ejbau
Diff Detail
Event TimelineComment Actions The symbols in the loader section should be the dynamic symbols in the general definition, so is it possible to use the original option --dyn-syms, and then implement the defined interface XCOFFDumper::printDynamicSymbols()? Comment Actions according to https://llvm.org/docs/CommandGuide/llvm-readobj.html --dyn-syms is "ELF SPECIFIC OPTIONS" in "MACH-O SPECIFIC OPTIONS" there is --macho-dsymtab We have XCOFF SPECIFIC OPTIONS options too. and the --dyn-syms looks do not express the xcoff loader section terminology. Comment Actions I was waiting on @Esme to respond to your latest comment, as it's a bit outside where I feel comfortable to make an informed decision. It does sound to me like dynamic symbols/loader section symbols are functionally the same thing (and also dynamic/loader section relocations). However, I also get the point that the terminology is different. Re. the documentation: it's ELF-specific, because no other format supported the option yet. That's not a reason not to move the option out of the ELF-specific options section. I note that in the Options.td file, --dyn-syms is already not in the ELF-specific area, so perhaps somebody has implemented it for another file format but forgot to update the docs? To address the different terminology point, how about the code be moved into printDynamicSymbols and then make --loader-section-symbols an alias of --dyn-syms. A similar approach could be adopted for the --loader-section-relocations` option, which would be similar to priting dynamic relocations for ELF, I expect.
Comment Actions
"MACH-O SPECIFIC OPTIONS"
I search the function "printDynamicTable()" which only implemented on ELFDumper.cpp.
I can make --loader-section-symbols an alias of --dyn-syms . but I can not move the code into printDynamicSymbols when user specific "--loader-section-symbols" , The output will look as Loader Section { Loader Section Symbols { Symbol { ...... } Symbol { ...... } } when user specific "--loader-section-relocation" , The output will look as Loader Section { Loader Section Relocations { Relocation { ...... } Relocation { ...... } } But If the code be moved into printDynamicSymbols" , it can not archive following when user specific "--loader-section-symbols --loader-section-relocation --loader-section-header" , The output will look as Loader Section { Header { ....... } Loader Section Symbols { Symbol { ...... } Symbol { ...... } Loader Section Relocations { Relocation { ...... } Relocation { ...... } } And I will add new option "--loader-section" later to print out all the content of loader section at one time. (equal to " loader-section-symbols + loader-section-relocation + loader-section-header + importLib"); which output all the loader section content into one Loader Section Loader Section { Loader Section Header Loader Section Symbols { Symbol { } } Loader Section Relocations { relocation { } } Loader section import libs { lib { } } etc... } Comment Actions Sorry for the late reply, in fact I'm not quite sure about using the existing --dyn-syms option or adding an XCOFF specific one, so I wait to see what others think. $ objdump base.xcoff -P loader Loader header: ... Dynamic symbols: ... Dynamic relocs: ... Import files: ... While objdump --dynamic-syms doesn't work. Comment Actions Thanks for the explanation, I follow what you're saying. One follow-up question: what is the motivation for having the outer "Loader Section" grouping to wrap the header/relocations/symbols? I'm not aware of any prior art for this style, at least within the llvm-readobj tooling (for example, in ELF, dynamic symbols, the dynamic section tags, and the dynamic relocations are all separate and ungrouped). (For clarity, I'm not opposed to a combined option that dumps them all, but am just wondering why the grouping is important). Comment Actions I think it is more clear that what data are belong to loader-section. it like all symbols are group into one symbols group(relocation too) . if you not agree to that group into a load section, I can change it. Comment Actions Typo in the patch topic: [XOCFF] -> [XCOFF].
Comment Actions address James' comment
Comment Actions Looks good, but probably worth @Esme taking a quick look to confirm that they're happy too.
Comment Actions there is a use of uninitialized value: |
Make this a plural name, as there's more than one symbol (typically). (The same will go for the relocation option in the next patch).