[LLVMdev] LLD input graph handling proposal

Shankar Easwaran 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.


Shankar Easwaran

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

More information about the llvm-dev mailing list