[LLVMdev] LLD improvement plan

[James Y Knight]

Nobody in this long thread appears to have yet explained why it's a bad
idea to allow atomic fragments of code/data (whatever you want to call
them: atoms, sections, who cares) to have more than one global symbol
attached to them in LLD's internal representation.

That seems like it'd provide the flexibility needed for ELF without hurting
MachO. If that change'd allow you to avoid splitting the linker into
two-codebases-in-one, isn't that preferable?


On Thu, May 7, 2015 at 9:38 AM, Joerg Sonnenberger <joerg at britannica.bec.de>
wrote:

> On Wed, May 06, 2015 at 09:28:54PM -0500, Shankar Easwaran wrote:
> > The atom model allowed lld to have a single intermediate
> > representation for all the formats ELF/COFF/Mach-O. The native model
> > allowed the intermediate representation to be serialized to disk
> > too. If the intermediate representations data structures are made
> > available to scripting languages most of all linker script script
> > layout can be implemented by the end user. A new language also can
> > be developed as most of the users need it and it can work on this
> > intermediate representation.
> >
> > The atom model also simplified a lot of usecases like garbage
> > collection and having the resolve to deal just with atoms. The
> > section model would sound simple from the outside but it it has its
> > own challenges like separating the symbol information from section
> > information.
>
> I'm sorry, but I don't get why any of this requires an atom based
> representation. Saying that a single intermediate representation for
> ELF/COFF on one hand and Mach-O on the other is ironic given the already
> mentioned hacks on various layers. Garbage collection doesn't become
> more expensive when attaching more than one symbol to each code/data
> fragment. Symbol resolution doesn't change when attaching more than one
> symbol to each code/data fragment. The list goes on. The single natural
> advantage is that you can use a single pointer to the canonical symbol
> from a code/data fragment and don't have to use a list/array. Given the
> necessary and expensive hacks for splitting sections into (pseudo)
> atoms, that doesn't feel like a win. So once again, what actual
> advantages for ELF or COFF have been created by the atom model? Mach-O
> hardly counts as it doesn't allow the flexibility of the section model
> as has been discussed before.
>
> Joerg
> _______________________________________________
> 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/20150511/f1687fb5/attachment.html>