[PATCH] D120913: [NFC][llvm-nm] create a new helper function exportSymbolNamesFromFiles for --export-symbols

[Digger Lin via Phabricator via llvm-commits]

DiggerLin added a comment.

In D120913#3369155 <https://reviews.llvm.org/D120913#3369155>, @jhenderson wrote:

> LGTM.
>
>> do we still another NFC patch
>
> To summarise, yes, we need another patch (at least one, possibly more), but I don't really mind what that patch looks like (i.e. it doesn't have to match what I suggested before).
>
> My key end goal of the suggestions I made in D112735 <https://reviews.llvm.org/D112735> was the removal of references to `ExportSymbols` causing early outs in otherwise common functions.

I do not think we can remove all the references to `ExportSymbols` , if we want to use the functionality (which extract object file out from archive, MachOUniversalBinary,TapiUniversal)  dumpSymbolNamesFromFile. we need at one ExportSymbols.

  we can  not implement as to get all the object files from input file into a vector(or list) , and then  dump and print the symbol for each object(not dump export symbol list), the reason: when there  are  error on get object file from input files. 

for example:

  1. there is warning on the input file1 as  '"sizes with -print-size for Mach-O files are always zero.\n";"
  2. get object file OK will input file 2
  3. there is some error on input file3 as "if (!ChildOrErr) { if (auto E = isNotObjectErrorInvalidFileType(ChildOrErr.takeError())) { error(std::move(E), Filename, C, ArchFlags.size() > 1 ? StringRef(I->getArchFlagName()) : StringRef()); } The current implement will output as:
1. error info for input file1. 2  obj21 .o (input file2) symbol1 , XX ,XX symbol2, XX, XX
2. obj22.o (input file2) symbol1 , XX,XX symbol2, XX,XX
3. error info for input file3(can not get obj31.o from input file3) obj32.o   (input file3) symbol1 , XX,XX symbol2, XX,XX error info for input file3(can not get obj33.o from input file3)

if we get all the object file out and put into a list and dump(and print symbols) from each object file of list.(it will print out all the warning or error information first) the output will be changed to

  1. error info for input file1.
  2. error info for input file3(can not get obj31.o from input file3)
  3. error info for input file3(can not get obj33.o from input file3) 4  obj21 .o (input file2) symbol1 , XX symbol2, XX
  4. obj22.o (input file2) symbol1 , XX symbol2, XX
1. obj32.o   (input file3) symbol1 , XX symbol2, XX

      

> I've highlighted the one section of code that has such references. I don't really mind how you achieve that end goal, as long as it leaves the code in a clean structural state (or at least as clean as it was before you started the export symbols work). My suggestion was merely one part of the wider plan, to ensure we had the information needed, and isn't necessarily the only approach, so if you have another approach then that's fine too.
>
> Away from that, there's at least one other minor improvement I'd like to see: rename `exportSymbolNamesFromFiles` to `dumpExportSymbolList`, as I think "dump" indicates "print something" more clearly than "export". The "export symbol list" part of the name then is what is being dumped, and nicely lines up with the option name.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120913/new/

https://reviews.llvm.org/D120913