[LLVMdev] LLD input graph handling proposal

Rui Ueyama ruiu at google.com
Fri Sep 20 17:29:32 PDT 2013

On Fri, Sep 20, 2013 at 5:08 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> 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. There are other concerns like the recursive processing
> of DT_NEEDED for ELF and the resulting implications for symbol
> resolution and locking.

Someone should certainly know about the input graph, but it isn't
necessarily be Resolver. In my proposal Linking Context gets update for
each step of linking from Resolver and makes a decision based on that. I
don't see why you think the search order would change in this model. I
think it shouldn't change.

I don't also understand if DT_NEEDED is related to this. DT_NEEDED is not
represented by input graph. And what is *recursive* processing of DT_NEEDED?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/1541c21a/attachment.html>

More information about the llvm-dev mailing list