[llvm-dev] LLD status update and performance chart

[Sean Silva via llvm-dev]

On Sun, Dec 18, 2016 at 7:21 AM, Rafael Avila de Espindola via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Rui Ueyama <ruiu at google.com> writes:
>
>
> > So, as a project, there is no anti-library policy in LLD. I think this is
> > the misunderstanding one side had. We already provide main-as-a-library
> > feature so that you can embed the linker to your program. We as a project
> > welcome other ideas to export linker features at a well-defined boundary.
> > For example, I think abstracting the file system access so that you can
> > hook file operations could be a well-defined, useful API for those who
> want
> > to do in-memory linking (I expressed that opinion already in this
> thread).
> > Just like LLVM, we won't guarantee API compatibility between releases,
> and
> > we are unlikely to be able to expose deep internals of the linker, but as
> > long as you think you found a reasonable coarse API boundary, there
> should
> > be nothing preventing you from bringing that to the table.
>
> It really depends on what is meant by a library.
>
> If we have to remove all calls to exit, all memory pools and all global
> variables I am very opposed to it.
>

It would depend. If there was a *really* compelling use case it might be
worth it.

I think what you're saying is basically: the linker is currently much
simpler and easier to maintain due to the fatal errors on corrupted input,
globals for the "context", etc.
We need a compelling use case to give that up, and nothing sufficiently
compelling has been presented. And currently the focus is on feature parity
with existing linkers and systems, so naturally we aren't exploring tons of
new use cases unless our users come to us with requests.

In fact, I would say that as we've implemented the linker and as a
community of LLD developers learned more about linkers, many of the
theoretical use cases seem less realistic than before.

We're still doing some of the things that the LLD originally set out to do.
For example, LLD/ELF has grown color diagnostics and will dig through DWARF
to give source locations (it's like one or two function calls into the LLVM
libraries to do this, so there's nothing left to "factor out" from LLD/ELF
itself).

-- Sean Silva


>
> lld is an actual project with actual value for its users. I really don't
> want to compromise its maintainability by turning every
>
> for (auto &X : check(...))
>
> into
>
> auto XsOrErr = ...;
> if (std::error_code EC = XsOrErr.getError())
>   return EC; // also update callers. Add more context to the return if
>              // you don't want to degrade the error message.
> auto &Xs = *XsOrErr;
> for (auto &X : Xs)
>
> In the name of a theoretical user. Really, can we put this on hold
> until the MachO linker has shown how to get its parts actually reused?
>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161218/3ec72b1f/attachment.html>