[LLVMdev] LLD improvement plan

[Rui Ueyama]

On Mon, May 11, 2015 at 11:21 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> 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 can think of a few, maybe more.

An atom model with multiple names is not as simple as before.

We still need to read all relocation tables to complete a graph as they
form edges, even for duplicate COMDAT sections.

It still can't model some section-linker features, such as "select largest"
COMDAT sections, because the new atom is still different from the section.
(This is not an issue if we really treat atoms like sections, but that
means in turn we would be going to create a Mach-O linker based on the
section model.)


>
>> 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/42bccb71/attachment.html>