[llvm-dev] LLD status update and performance chart

[Rafael Avila de Espindola via llvm-dev]

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