[llvm-dev] lld: ELF/COFF main() interface

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 7 07:17:30 PST 2016


On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> In the process of migrating from old lld ELF linker to new (previously
> ELF2) I noticed the interface lost several important features (ordered by
> importance for my use case):
>
> 1. Detecting errors in the first place. New linker seems to call exit(1)
> for any error.
>
> 2. Reporting messages to non-stderr outputs. Previously all link functions
> had a raw_ostream argument so it was possible to delay the error output,
> aggregate it for multiple linked files, output via a different format, etc.
>
> 3. Linking multiple outputs in parallel (useful for test drivers) in a
> single process. Not really an interface issue but there are at least two
> global pointers (Config & Driver) that refer to stack variables and are
> used in various places in the code.
>
> All of this seems to indicate a departure from the linker being useable as
> a library. To maintain the previous behavior you'd have to use a linker
> binary & popen.
>
> Is this a conscious design decision or a temporary limitation?
>

That the new ELF and COFF linkers are designed as commands instead of
libraries is very much an intended design change.


> If it's a limitation, how would one go about fixing this? I'm not too
> familiar with the idiomatical error handling in LLVM. Normally in this
> situation I'd just throw from error() but lld is probably compiled without
> exceptions. Is ErrorOr the established practice? How does LLVM generally
> deal with error handling for parsers (like linker script parser) where it's
> a lot of mutually recursive functions where every single one can fail?
>

Since it's as designed, please run the linker as an external command using
fork/exec (or wrappers of them) instead of trying to use that inside the
same process.


> Arseny
>
> _______________________________________________
> 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/20160107/aaefe17a/attachment.html>


More information about the llvm-dev mailing list