[LLVMdev] LLD input graph handling proposal

[Shankar Easwaran]

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.

Thanks

Shankar Easwaran

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