llvm dev - Dec 2016 - LLD status update and performance chart

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.

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

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>

Sean Silva <chisophugis at gmail.com> writes:
> 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.
Yes, the is good expansion of my position. To the best of my knowledge
the only two actual code "chunks" in lld that have correspondence in
llvm are the thread pool and the relocation application.

I think everyone agrees on the thread pool, it should be unified and one
day we should be able to use just the c++ standard library.

The relocation application is not clear and the lld one might not even
be in its final form, so it is too early to tell.

Cheers,
Rafael