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

[Sean Silva via llvm-dev]

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

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

My recollection is that the plan was to basically factor out of COFF/ELF2
and into LLVM whenever we saw the need to share functionality (not just
between COFF and ELF2, or with MCJIT, but in general).

I guess the question is whether eventually enough stuff will be factored
out into libraries that we will have a coherent set of reusable "linker
libraries" (in which case it might make sense to pull those out of LLVM and
into lld/{include,lib}) and the COFF/ELF2 command line programs will
naturally become "thin wrappers around the library code".

At this point it is unclear (to me, at least) whether that will happen or
not. If not, then in order to meet the use case of linker functionality in
a library, we will have to take the command line programs and do some
straightforward transformations to get a "main() in a library"  type
interface (MemoryBuffer's instead of filenames, etc.) to meet those use
cases.

Of course, the "main() in a library" scenario is a bit depressing and we
should avoid it if possible, since it really does go against the whole LLVM
philosophy. The atom LLD warned us of the dangers of
overgeneralizing/overabstracting important details/specifics that linkers
actually have to deal with, so it's natural that COFF/ELF2 is a reaction to
this. We just need to make sure that we find the right middle ground and
don't get stuck in the opposite extreme that the atom LLD got stuck in.
There is a saying that "you have to go too far to know how far is far
enough"; I think right now we are exploring the "not a library / not
generalized / not abstracted" side of things and will incrementally pull
back towards the right middle ground as we gain experience and new and
interesting use cases come within reach.

-- Sean Silva


> (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.
>
> _______________________________________________
> 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/20160113/3bded610/attachment.html>