[llvm-commits] [llvm] r62279 - in /llvm/trunk: docs/ include/llvm/ include/llvm/Support/ lib/Analysis/IPA/ lib/Archive/ lib/AsmParser/ lib/Bitcode/Reader/ lib/Bitcode/Writer/ lib/CodeGen/ lib/CodeGen/AsmPrinter/ lib/CodeGen/SelectionDAG/ lib/Exec

[Nick Lewycky]

Rafael Espindola wrote:
> 2009/1/16 Nick Lewycky <nicholas at mxc.ca>:
>> Do we need to make any changes to libLTO? If I understand right, we
>> don't create any symbols for privates, so we should just skip over all
>> private globals when listing them in libLTO?
> 
> When talking to the linker? We should skip all local (private and
> internal) values. The linker (at this point) only needs to know the
> global symbols. It only cares for local symbols once we have delivered
> the final binary.
> 
> This is gold, not sure about the Darwin LD, but I assume it is similar.

Unlike gold, the Darwin LD builds up the symbol table in the first pass. 
It does want to hear about all local symbols up front.

The gold plugin filters out all the internal symbols. See line 181:

     lto_symbol_attributes attrs = lto_module_get_symbol_attribute(cf.M, i);
     if ((attrs & LTO_SYMBOL_SCOPE_MASK) == LTO_SYMBOL_SCOPE_INTERNAL)
       continue;

We could either add an LTO_SYMBOL_SCOPE_PRIVATE or just have it never 
list those symbols. Either one works for the linker, but let me ask 
this: should 'nm' list private symbols? Darwin's nm uses libLTO to when 
queried about .bc files, so if nm ought to show them, libLTO needs to 
return them and we need to add a new enum.

Nick