[PATCH] D35639: [ThinLTO] Prevent dead stripping and internalization of symbols with sections

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 19 20:02:03 PDT 2017


pcc added a comment.

In https://reviews.llvm.org/D35639#815587, @tejohnson wrote:

> In https://reviews.llvm.org/D35639#815579, @pcc wrote:
>
> > In https://reviews.llvm.org/D35639#815578, @tejohnson wrote:
> >
> > > In https://reviews.llvm.org/D35639#815234, @pcc wrote:
> > >
> > > > Another possibility is to handle this in the client (i.e. the linker) instead. The client has the best idea of whether a given section is a GC root; ELF linkers can set VisibleToRegularObj on any symbol in a section named like a C identifier, and other linkers can do whatever is appropriate for their object format.
> > >
> > >
> > > I don't see how to get the presence of a section or the section name for a symbol when walking the symbols? I.e. either in gold-plugin via the symbol info from the linker, or in LTO::addModuleToGlobalRes via the InputFile:Symbol?
> >
> >
> > We'd need to add that information to the irsymtab and expose it via InputFile::Symbol.
>
>
> That's what I was afraid of. =(  That seems quite a bit more extensive than simply checking whether the GV has a section and blocking internalization. 
>  If we were to go the route you are suggesting, it looks like currently we don't iterate through the InputFile until we invoke the LTO API, when adding a module. I guess we would have to then iterate through those and update the global resolutions earlier, e.g. in the gold-plugin? I.e. in order to make it ELF specific.


I don't follow your point about global resolutions, this should be purely a local analysis (from the linker's perspective at least). In both the gold plugin and lld an InputFile is available at the point where we compute the resolution for each symbol, so it should be a matter of copying the property from the InputFile symbol to the resolution.


https://reviews.llvm.org/D35639





More information about the llvm-commits mailing list