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

[Rui Ueyama via llvm-dev]

On Thu, Jan 7, 2016 at 2:56 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

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

There was a discussion that we would keep the same entry point for the old
and the new, but I don't remember if I promised that we were going to
organize the new linker as a library. The new one is designed as a command
from day one. (Precisely speaking, the original code propagates errors all
the way up to the entry point, so you can call it and expect it to always
return. Rafael introduced error() function later and we now depends on that
function does not return.)

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

I'm not against organizing it as a library as long as it does not make
things too complicated, and I guess reorganizing the existing code as a
library is relatively easy because it's still pretty small, but I don't
really want to focus on that until it becomes usable as an alternative to
GNU ld or gold. I want to focus on the linker features themselves at this
moment. Once it's complete, it becomes more clear how to organize it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160107/7ef60916/attachment.html>