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

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 7 14:56:00 PST 2016


On Thu, Jan 7, 2016 at 7:18 AM Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>

I disagree.

During the discussion, there was a *specific* discussion of both the new
COFF port and ELF port continuing to be libraries with a common command
line driver.

If you want to consider changing that, we should have a fresh (and broad)
discussion, but it goes pretty firmly against the design of the entire LLVM
project. I also don't really understand why it would be beneficial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160107/65168e5c/attachment.html>


More information about the llvm-dev mailing list