[PATCH] D27709: [LLD][ARM] Add support for thunks to undefined non-weak symbols
Peter Smith via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Dec 14 03:45:16 PST 2016
peter.smith added a comment.
I think it depends on what the precise meaning of Shared and Undefined. At the moment I think the distinction is:
- The symbol is defined in a known shared object.
- The symbol details such as type, binding and version are known.
- The shared object has been added as a dependency to the output.
- The shared object defining the symbol can be found from the SymbolBody.
- We have a reference to a symbol but no definition.
- When linking a shared library we assume that the dynamic loader will find a suitable definition from the executable/shared library or error.
- In all other cases (besides relocatable -r) an undefined non-weak symbol is an error.
- There is no input file associated with the symbol.
With those definitions I don't think that there is a problem with Thunks on undefined symbols. There is a call to a symbol that we know nothing about and we are going to rely on the dynamic loader to sort it out for us. As we need the dynamic loader we will necessarily need a PLT entry. The Thunk is from the caller to the PLT entry.
If we make the change to say that in Shared Libraries Undefined symbols become Shared there will be some implications. I think the definition of Shared has to be weakened to something closer to Undefined and any calling code that needs to know about the distinctions will have to do some extra work. For example if we have some diagnostics that print out the shared library name for the Shared symbol will need to test to see if it actually has an associated file.
- A SharedUndefined symbol kind that could replace the if (body.isUndefined() && body.isShared()) with body.isUndefinedShared(), that could support a Thunk and we could keep Undefined to mean error if not defined.
- Don't solve this problem right now and start work on range-extension thunks. As there can be more than one Thunk per symbol with range extension thunks we'll need to do something differently anyway.
I'm happy to try out the alternatives. I'm on vacation from Monday till the end of the year so I'll probably only be able to get a small change done by then.
More information about the llvm-commits