[LLVMdev] LLD improvement plan

[David Blaikie]

On Mon, May 11, 2015 at 11:13 AM, Rui Ueyama <ruiu at google.com> wrote:

> If you attach two ore more symbols along with offsets to a chunk of data,
> it would be a pretty similar to a section. That means that if you want to
> do something on the atom model, now you have to treat the atoms like
> sections.
>

What do you lose/pay by having to treat the atoms like sections?


> I looks like a bad mix of the two.
>
> 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?
>>
>>
>> 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
>>
>>
>
> _______________________________________________
> 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/0208f4a2/attachment.html>