[LLVMdev] LLD improvement plan

[Davide Italiano]

On Sun, May 3, 2015 at 1:50 PM, Alex Rosenberg <alexr at leftfield.org> wrote:
> On May 1, 2015, at 7:06 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> On Fri, May 1, 2015 at 6:46 PM Nick Kledzik <kledzik at apple.com> wrote:
>>
>>
>> On May 1, 2015, at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote:
>>
>> The atom model is not the best model for some architectures
>>
>>
>> The atom model is a good fit for the llvm compiler model for all
>> architectures.  There is a one-to-one mapping between llvm::GlobalObject
>> (e.g. function or global variable) and lld:DefinedAtom.
>
>
> I'm not sure how that's really relevant.
>
> On some architectures, the unit at which linking is defined to occur isn't a
> global object. A classic example of this are architectures that have a hard
> semantic reliance grouping two symbols together and linking either both or
> neither of them.
>
>>
>> The problem is the ELF/PECOFF file format.   (Actually mach-o is also
>> section based, but we have refrained from adding complex section-centric
>> features to it, so mapping it to atoms is not too hard).
>>
>> I’d rather see our effort put to moving ahead to an llvm based object file
>> format (aka “native” format) which bypasses the impedance mismatch of going
>> through ELF/COFF.
>
>
> We still have to be able to (efficiently) link existing ELF and COFF objects
> though? While I'm actually pretty interested in some better object file
> format, I also want a better linker for the world we live in today...
>
>
> For us, this is secondary. A major part of the reason we started lld was to
> embrace the atom model, that is to bring the linker closer to the compiler.
> We have a lot of long-term goals that involve altering the traditional
> compiler/linker flow, with a goal toward actual improvements in developer
> workflow. Just iterating again on the exact same design we've had since the
> '70s is not good enough.
>
> The same is true of other legacy we're inheriting like linker scripts. While
> we want them to work and work efficiently, we should consider them part of
> necessary legacy to support and not make them fundamental to our internal
> design. This planning will allow us latitude to make fundamental
> improvements. We make similar decisions across LLVM all the time, take our
> attitude toward __builtin_constant_p() or nested functions for example.
>
> We've been at this for several years. We had goals and deadlines that we're
> not meeting. We've abandoned several significant design points so far
> because Rui is making progress on PECOFF and jettisons things and we let it
> slide because of his rapid pace.
>
> Core command line? GONE.
> Round-trip testing? GONE.
> Native file format? GONE.
> And now we're against the Atom model?
>
> I don't want a new linker that just happens to be so mired in the same
> legacy that we've ended up with nothing but a gratuitous rewrite with a
> better license.
>
> We want:
>
> * A new clean command line that obviates the need for linker scripts and
> their incestuous design requirements.
> * lld is thoroughly tested, including the efficient new native object file
> format it provides.
> * lld is like the rest of LLVM and can be remixed such that it's built-in to
> the Clang driver, should we choose to.
> * We can have the linker drive compilation such that objects don't leave the
> disk cache before being consumed by the linker.
>
> Perhaps we should schedule an in-person lld meeting. Almost everybody is in
> the Bay Area. I'm happy to host if we think this will help.
>
> Alex
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

There are projects (like FreeBSD) which need a new linker.
In the FreeBSD case it is mainly motivated by a licensing issue, but I
feel like this doesn't mean that the linker needs to be slower or
harder to hack on because we want to treat as first class citizen a
format that has been largely unmaintained in the last 6 months at
least and as second class citizen widespread formats like ELF. I'm
personally excited about the idea of a new format and I would like to
spend some time thinking about it, although I always try to be
pragmatic.
I will be happy to discuss this further in person.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare