This is an archive of the discontinued LLVM Phabricator instance.

[XCOFF] llvm-readobj support display symbol table of loader section of xcoff object file.
ClosedPublic

Authored by DiggerLin on Oct 13 2022, 8:35 AM.

Diff Detail

Event Timeline

DiggerLin created this revision.Oct 13 2022, 8:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 13 2022, 8:35 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
DiggerLin requested review of this revision.Oct 13 2022, 8:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 13 2022, 8:35 AM
DiggerLin edited the summary of this revision. (Show Details)Oct 13 2022, 8:36 AM
Esme added a comment.Oct 20 2022, 8:50 PM

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()?

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()?

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.

gentle ping @jhenderson and @Esme .

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.

llvm/docs/CommandGuide/llvm-readobj.rst
341

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).

DiggerLin added a comment.EditedOct 27 2022, 1:22 PM

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.

"MACH-O SPECIFIC OPTIONS"
there is --macho-dsymtab in MachO, if move out the ELF-specific options , do we want to delete MachO's "--macho-dsymtab" instead of using --dyn-syms

--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?

I search the function "printDynamicTable()" which only implemented on ELFDumper.cpp.

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 printing dynamic relocations for ELF, I expect.

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...
}
Esme added a comment.Oct 28 2022, 2:31 AM

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.
I noticed that the objdump from AIX system tool kits prints the loader section (together with its symbols and relocations) with the XCOFF specific option -P loader:

$ objdump base.xcoff -P loader

Loader header:
...
Dynamic symbols:
...
Dynamic relocs:
...
Import files:
...

While objdump --dynamic-syms doesn't work.
From that standpoint, I have no objection to what Digger is doing now.

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).

DiggerLin updated this revision to Diff 472352.Nov 1 2022, 10:47 AM

addressed James' comment.

DiggerLin added a comment.EditedNov 1 2022, 10:56 AM

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).

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.

Typo in the patch topic: [XOCFF] -> [XCOFF].

llvm/include/llvm/Object/XCOFFObjectFile.h
247

Here and throughout: I'd change LDHeader to LoaderHeader, as it avoids the need for metal gymnastics to underestand what "LD" means here.

llvm/lib/Object/XCOFFObjectFile.cpp
93
106–107

This is undefined behaviour. From cppreference.com:

It is undefined behavior to read from the member of the union that wasn't most recently written.

In other words, your design of the struct isn't guaranteed to work according to the C++ coding standard. You need to change it so that you can use a different mechanism to identify whether the name is in the string table or not.

llvm/test/tools/llvm-readobj/XCOFF/loader-section-symbol-invalid.test
38 ↗(On Diff #472352)

Get rid of extra blank line.

39 ↗(On Diff #472352)
llvm/tools/llvm-readobj/XCOFFDumper.cpp
161
216

As asked before, please take more care with your code before uploading for review. I have repeatedly pointed out that functions should not start with a blank line.

I'm sorry, but there may come a point where I simply won't be willing to review the patch until you've got rid of all the trivial errors like this, because it wastes my time reviewing it and having to comment on all these issues every time.

222–227
245
248

As far as I can tell, the else block here is identical to the if part, except for different types. Put them into a helper template function to avoid code duplication.

255
DiggerLin retitled this revision from [XOCFF] llvvm-readobj support display symbol table of loader section of xcoff object file. to [XCOFF] llvvm-readobj support display symbol table of loader section of xcoff object file..Nov 8 2022, 7:21 AM
DiggerLin updated this revision to Diff 474305.Nov 9 2022, 10:26 AM
DiggerLin marked 7 inline comments as done.

address comment

DiggerLin added inline comments.Nov 9 2022, 10:27 AM
llvm/lib/Object/XCOFFObjectFile.cpp
106–107

thanks for point out.

llvm/tools/llvm-readobj/XCOFFDumper.cpp
216

sorry about that. Actually I always take a careful review when I uploaded the code. But sorry that there are still some trivial error. I will put more work on the review when uploaded.

248

thanks

jhenderson added inline comments.Nov 10 2022, 12:43 AM
llvm/include/llvm/Object/XCOFFObjectFile.h
229–232

Use C++ style struct naming. I'm not a big fan of the struct name either. We don't generally call any of our types "...Type", since that part of the name is typically redundant (it will be used as a type or not as a type, so the usage tells us it's a type). How about simply "SymbolNameOffset"? The usage will make it clear it's not a pure integer, I think. Other ideas are welcome too.

(If the XCOFF spec has a sepcific name for this struct, then it's fine to use that name, I guess).

llvm/lib/Object/XCOFFObjectFile.cpp
93

Marked as done, but this comment hasn't been addressed. Please don't mark comments as done if you haven't done them.

llvm/test/tools/llvm-readobj/XCOFF/loader-section-symbol-invalid.test
1 ↗(On Diff #474305)
llvm/tools/llvm-readobj/XCOFFDumper.cpp
161

Updated comment still doesn't completely match my suggestion. Please fix.

217–221

Do these two calculations need checking to make sure they are within the file (in case of malformed input)?

DiggerLin updated this revision to Diff 474772.Nov 11 2022, 8:08 AM
DiggerLin marked 7 inline comments as done.

address James' comment

llvm/include/llvm/Object/XCOFFObjectFile.h
229–232

We already define "NameOffset" in the LoaderSectionSymbolEntry32, so we do not need the "Symbol" in SymbolNameOffset. I change to use the NameOffsetInStrTbl.

llvm/lib/Object/XCOFFObjectFile.cpp
93

I used the abbr Name in function name , otherwise the function name is too long. For example:
Sec for Section.
StrTbl for StringTable.
Load for Loader.

llvm/test/tools/llvm-readobj/XCOFF/loader-section-symbol-invalid.test
1 ↗(On Diff #474305)

thanks

llvm/tools/llvm-readobj/XCOFFDumper.cpp
161

thanks

217–221

I added check code for it . thanks

jhenderson accepted this revision.Nov 16 2022, 12:52 AM

Looks good, but probably worth @Esme taking a quick look to confirm that they're happy too.

llvm/lib/Object/XCOFFObjectFile.cpp
93

I'm okay with some abbreviations (Sec, Sym and StrTbl are all fine), but "Load" -> "Loader" is not an obvious one to me, hence my objection.

Regarding marking things as done - if you disagree with my comment, that's fine, but please say so and explain why so that we can have a discussion.

This revision is now accepted and ready to land.Nov 16 2022, 12:52 AM
DiggerLin marked an inline comment as done.Nov 16 2022, 6:13 AM
DiggerLin added inline comments.
llvm/lib/Object/XCOFFObjectFile.cpp
93

OK, thanks.

DiggerLin retitled this revision from [XCOFF] llvvm-readobj support display symbol table of loader section of xcoff object file. to [XCOFF] llvm-readobj support display symbol table of loader section of xcoff object file..Nov 18 2022, 9:39 AM
vitalybuka reopened this revision.Nov 19 2022, 9:57 AM
vitalybuka added a subscriber: vitalybuka.

there is a use of uninitialized value:
https://lab.llvm.org/buildbot/#/builders/5/builds/29299

This revision is now accepted and ready to land.Nov 19 2022, 9:57 AM

(Note, a typo in the commit [XCOFF] llvvm-readobj ...)

DiggerLin marked an inline comment as done.Nov 21 2022, 6:47 AM

(Note, a typo in the commit [XCOFF] llvvm-readobj ...)

fixed. thanks

there is a use of uninitialized value:
https://lab.llvm.org/buildbot/#/builders/5/builds/29299

fixed , thanks