[LLVMdev] LLD improvement plan

[David Blaikie]

On Mon, May 11, 2015 at 10:56 AM, James Y Knight <jyknight at google.com>
wrote:

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

+1 I'd be curious to understand this too.


>
>
> 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
>>
>
>
> _______________________________________________
> 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/f767b933/attachment.html>