[PATCH] D101569: [LLD] [COFF] Fix automatic export of symbols from LTO objects

[Reid Kleckner via Phabricator via llvm-commits]

rnk added inline comments.


================
Comment at: lld/COFF/Driver.cpp:1221
+          if (objSym.getName() == e.name) {
+            if (!objSym.isExecutable())
+              e.data = true;
----------------
mstorsjo wrote:
> rnk wrote:
> > mstorsjo wrote:
> > > Here we end up iterating over all symbols in the input bitcode file, to find the one we're looking at, to figure out whether it's data or a function. Not pretty...
> > Yeah, it would be nice to figure out how to avoid this, since it's O(n^2)-ish.
> > 
> > One way would be to store this bit directly on the DefinedRegular symbol object.
> > 
> > Another way would be to start making fake, synthetic SectionChunk objects for symbols from bitcode files. We could have the standard text, data, rdata, bss sections, for example. This would make the previous conditional unnecessary. That seems better.
> > 
> > The least invasive way would be to separately iterate over the bitcode input files and look their symbols up in the symbol table and use that to create exports. However, symbol resolution is already expensive, and this is basically a second symbol resolution phase.
> > 
> > I kind of lean towards the second option. It leads to less null checks in the long run.
> You mean your preference is synthetic section chunks?
> 
> That does sound nice as it'd avoid null checks, but wouldn't it be a huge waste (both mem and time) to do that for all bitcode object file symbols, for the odd chance of wanting to inspect some of them for exporting - just for the short period of time until we replace them with the LTO compiled output?
> 
> Or should there be like 1 common fake section chunk used for all LTO symbols, for each symbol type (func/data)?
I was thinking we could have one fake section chunk for the standard types of LLVM IR GlobalValues: .text for Function, .data for GlobalVariable, .rdata for Constant, etc. Something like that. I think it's just a matter of passing extra parameters to addRegular in BitcodeFile::parse.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101569