[llvm-commits] [patch][pr11866] Drop linkonce_odr symbols from the symbol table when safe

[Rafael Espíndola]

ping

On 16 June 2012 20:12, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> The attached patch fixes PR11866.
>
> My original idea on how to fix it (see comment 3 in that bug) is a bit
> hard to implement. The problem is that the LTO infrastructure reports
> an undefined reference when it sees a declaration.  For example, a
> file with just
>
> declare void @foo()
>
> is going to show up as having an undefined reference. Simple cases
> like this should be simple to filter out, but we also have to handle
> declarations used only in available_externally "definitions" like the
> ones in pr13124. Doable, but I think I found an easier way.
>
> Gold's plugin api was updated some time ago to let the plugins know
> that a symbol is not used from any ELF file, but gold would still put
> it in a symbol table if present. In this case the plugin is free to
> drop the symbol if it knows it doesn't need to go in a shared object's
> symbol table. That is what this patch does.
>
> In detail:
>
> * The LTO code is updated to record which linkonce_odr functions  and
> constants don't have their address taken (or have an unnamed_addr
> flag).
> * The plugin still reports linkonce_odr symbols to gold.
> * The plugin doesn't force LTO to keep symbols that gold tells us
> would be needed only for the symbol table and have been marked as
> noted above.
>
> When linking clang with LTO (and -export-dynamic,  so it is
> effectively a DSO), the number of linkonce_odr symbols goes from 1907
> to 63. Of these 63
>
> * 61 are typeinfo names, so we do need to keep them visible since
> their address is compared.
> * 2 are linkonce_odr globals, which we also have to keep visible to
> observe mutations.
>
> CCing nleycky for opinions on the plugin changes and the linker guys
> to know if this is also a reasonable way to go for lld.
>
> Cheers,
> Rafael