[LLVMdev] LLD input graph handling proposal
shankare at codeaurora.org
Fri Sep 20 17:46:43 PDT 2013
On 9/20/2013 7:08 PM, Joerg Sonnenberger wrote:
> On Fri, Sep 20, 2013 at 04:39:04PM -0700, Rui Ueyama wrote:
>> I don't want to make Resolver to have a reference to input graph. The point
>> of this proposal is to separate input graph handling from Resolver and
>> instead making Linker Context to do that task.
> That was the part of the original proposal I didn't agree with and I
> still don't do. While the resolver shouldn't have to deal with the
> details of the command line, it certainly should know about the input
> graph. I wouldn't be surprised if it can make a significant difference
> for group processing whether a DFS or BFS is applied, even if the result
> doesn't change.
Resolver still doesnot deal with details of the command line. Its only
supposed to read inputs as specified in command line order (for ELF).
Darwin does things differently.
nextFile encompasses all the details of symbol resolution on which file
to iterate next during linking.
> There are other concerns like the recursive processing
> of DT_NEEDED for ELF and the resulting implications for symbol
> resolution and locking.
With nextFile, and the resolver state, the LinkingContext is in full
control of the resolver operation.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
More information about the llvm-dev