Hi Nick, I am planning to work on adding support for definining expressions for the Gnu flavor. Currently Gnu ld supports an option --defsym symbol=expression. The expression may be composed of other symbols. Any symbol that appears in the expression, gets its value from the output symbol value (address of the symbol in the output file). In addition the symbol only gets defined if and only if there is a relocation, that refers to the symbol. I was wondering how to accomplish this with lld. One thought that I had was to take list of user defined symbols and the expressions associated with the symbols and evaluate at the time of writing the output file. The problem with that is a) if the expression uses a symbol thats not defined anywhere else except the defsym expression, the symbol would get garbage collected. b) Supporting linker scripts which create new symbols, will be an issue. What are your thoughts ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
On Thu, Aug 22, 2013 at 12:54 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:> Hi Nick, > > I am planning to work on adding support for definining expressions for the > Gnu flavor. > > Currently Gnu ld supports an option --defsym symbol=expression. The > expression may be composed of other symbols. > Any symbol that appears in the expression, gets its value from the output > symbol value (address of the symbol in the output file). > > In addition the symbol only gets defined if and only if there is a > relocation, that refers to the symbol. > > I was wondering how to accomplish this with lld. One thought that I had > was to take list of user defined symbols and the expressions associated > with the symbols and evaluate at the time of writing the output file. > The problem with that is > > a) if the expression uses a symbol thats not defined anywhere else except > the defsym expression, the symbol would get garbage collected. > b) Supporting linker scripts which create new symbols, will be an issue. > > What are your thoughts ?Linker scripts have the same need. My idea for this was to allow atoms to have an associated expression tree and would have references to all symbols in that tree. The resolver wouldn't need any special handling for this, and the backend would just need to evaluate the expression at the end. - Michael Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130822/4be5759f/attachment.html>
On Aug 22, 2013, at 1:32 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:> On Thu, Aug 22, 2013 at 12:54 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > I am planning to work on adding support for definining expressions for the Gnu flavor. > > Currently Gnu ld supports an option --defsym symbol=expression. The expression may be composed of other symbols. > Any symbol that appears in the expression, gets its value from the output symbol value (address of the symbol in the output file). > > In addition the symbol only gets defined if and only if there is a relocation, that refers to the symbol. > > I was wondering how to accomplish this with lld. One thought that I had was to take list of user defined symbols and the expressions associated with the symbols and evaluate at the time of writing the output file. > The problem with that is > > a) if the expression uses a symbol thats not defined anywhere else except the defsym expression, the symbol would get garbage collected. > b) Supporting linker scripts which create new symbols, will be an issue. > > What are your thoughts ? > > Linker scripts have the same need. My idea for this was to allow atoms to have an associated expression tree and would have references to all symbols in that tree. The resolver wouldn't need any special handling for this, and the backend would just need to evaluate the expression at the end.Agreed. On one hand, this sounds like an AbsoluteAtom because it has no content and no section, but has an address. On the other hand, it needs References to the symbols used in its expression and only DefinedAtoms can have content. But DefinedAtoms are normally laid out and assigned addresses. One way to work this in would be to make them DefinedAtoms of size zero, with a new ContentType that the ELF Writer knows does not need an address assigned. The References to each symbol used in its expression ensures that all needed symbols exist and are not dead stripped. The References will need some Kind the ELF Writer knows is not a relocation, but there for the expression evaluator to find the addresses of the symbols used. -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130822/f44b4263/attachment.html>