[LLVMdev] LLD improvement plan

[Chandler Carruth]

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


>
>
>
>
> *One symbol resolution model doesn’t fit all*
>
>
> Yes, the Resolver was meant to call out to the LinkingContext object to
> direct it on how to link.  Somehow that got morphed into “there should be a
> universal data model that when the Resolver process the input data, the
> right platform specific linking behavior falls out”.
>
>
> -Nick
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150502/49e18575/attachment.html>