Joerg:> I propose to add the ability to ignore undefined symbols during initial > resolution, and then postprocess only those undefines for the second time > after the pass manager execution.Do you want to do that before or after dead code elimination? I think dead code elimination should be performed after all possible object code modifications done by lld. Therefore, it should be done after undefines' postprocessing as well. Shankar:> I propose to add the ability to ignore undefined symbols during initial > resolution, and then postprocess only those undefines for the second time > after the pass manager execution.I came across this same problem, and was planning on adding a notifyUndefinedSymbol to the LinkingContext, if the linker wants to add a defined symbol and coalesce it, it would be possible. Do you think this will work for your case too ? With this option, I don't see: - how to postpone processing and reaction on undefines. If the callback is called from within Resolver::resolve(), you should react on it immediately, because otherwise the code will still fail in Resolver::resolve(). - how to know if a symbol is needed within the callback body. The need of any symbol is determined in some other place. So I need to keep a sort of indication (boolean flags, whatever) to know which symbols are really needed. - the exact interface of notifyUndefinedSymbol callback. If it receives `StringRef` name of the undefined symbol, what reaction should be? Should it return new symbols to add back to the caller as `const Atom*`? Thanks, Denis. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/9a5c09dc/attachment.html>
On 2/19/2015 3:58 AM, Denis Protivensky wrote:> Joerg: >> I propose to add the ability to ignore undefined symbols during initial >> resolution, and then postprocess only those undefines for the second time >> after the pass manager execution. > Do you want to do that before or after dead code elimination? > I think dead code elimination should be performed after all possible object code modifications done by lld. Therefore, it should be done after undefines' postprocessing as well.Gnu does dead code elimination before undefines are reported. So if a function is not called and it has a undefined reference its would not be an undef.> > Shankar: >> I propose to add the ability to ignore undefined symbols during initial >> resolution, and then postprocess only those undefines for the second time >> after the pass manager execution. > I came across this same problem, and was planning on adding a > notifyUndefinedSymbol to the LinkingContext, if the linker wants to add > a defined symbol and coalesce it, it would be possible. > > Do you think this will work for your case too ? > With this option, I don't see: > - how to postpone processing and reaction on undefines. If the callback is called from within Resolver::resolve(), you should react on it immediately, because otherwise the code will still fail in Resolver::resolve(). > - how to know if a symbol is needed within the callback body. The need of any symbol is determined in some other place. So I need to keep a sort of indication (boolean flags, whatever) to know which symbols are really needed. > - the exact interface of notifyUndefinedSymbol callback. If it receives `StringRef` name of the undefined symbol, what reaction should be? Should it return new symbols to add back to the caller as `const Atom*`?notifyUndefinedSymbol will allow the context to coalesce the undefined atom with a defined atom. Atom *notifyUndefinedSymbol(StringRef name) could be the interface.> Thanks, > Denis. >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
+ Nick On 2/19/2015 9:00 AM, Shankar Easwaran wrote:> On 2/19/2015 3:58 AM, Denis Protivensky wrote: >> Joerg: >>> I propose to add the ability to ignore undefined symbols during initial >>> resolution, and then postprocess only those undefines for the second >>> time >>> after the pass manager execution. >> Do you want to do that before or after dead code elimination? >> I think dead code elimination should be performed after all possible >> object code modifications done by lld. Therefore, it should be done >> after undefines' postprocessing as well. > Gnu does dead code elimination before undefines are reported. So if a > function is not called and it has a undefined reference its would not > be an undef. >> >> Shankar: >>> I propose to add the ability to ignore undefined symbols during initial >>> resolution, and then postprocess only those undefines for the second >>> time >>> after the pass manager execution. >> I came across this same problem, and was planning on adding a >> notifyUndefinedSymbol to the LinkingContext, if the linker wants to add >> a defined symbol and coalesce it, it would be possible. >> >> Do you think this will work for your case too ? >> With this option, I don't see: >> - how to postpone processing and reaction on undefines. If the >> callback is called from within Resolver::resolve(), you should react >> on it immediately, because otherwise the code will still fail in >> Resolver::resolve(). >> - how to know if a symbol is needed within the callback body. The >> need of any symbol is determined in some other place. So I need to >> keep a sort of indication (boolean flags, whatever) to know which >> symbols are really needed. >> - the exact interface of notifyUndefinedSymbol callback. If it >> receives `StringRef` name of the undefined symbol, what reaction >> should be? Should it return new symbols to add back to the caller as >> `const Atom*`? > notifyUndefinedSymbol will allow the context to coalesce the undefined > atom with a defined atom. > > Atom *notifyUndefinedSymbol(StringRef name) could be the interface. > >> Thanks, >> Denis. >> > >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
On Thu, Feb 19, 2015 at 01:58:59AM -0800, Denis Protivensky wrote:> > Do you want to do that before or after dead code elimination? > I think dead code elimination should be performed after all possible > object code modifications done by lld. Therefore, it should be done > after undefines' postprocessing as well.How do you then make sure to not export redundant symbols? Consider _GLOBAL_OFFSET_TABLE_ -- if the only user is in a dead function, it should not be in the symbol table. Same for __tls_get_addr. Joerg