[llvm-dev] LLD: creating linker-generated sections as input sections instead of output sections

[Eugene Leviant via llvm-dev]

Is anyone already working on it? If not then I can take this task.

2016-10-20 2:46 GMT+03:00 Rui Ueyama <ruiu at google.com>:
> On Wed, Oct 19, 2016 at 3:34 AM, Peter Smith via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> Thanks for the RFC.
>>
>> I'm in favour of the option of creating InputSections for some linker
>> generated content. I think it would add extra flexibility to the
>> linker. ARM's proprietary linker uses the equivalent of InputSections
>> with a pseudo linker defined ObjectFile for SHF_ALLOC content. As
>> Eugene points out it isn't always appropriate for meta-data sections.
>
>
> It is encouraging that the ARM's linker uses the same scheme.
>
>> In particular it would be great to have a pseudo InputFile that local
>> symbols could be generated in as this would make supporting mapping
>> symbols[*] in linker generated sections much easier. It would also
>> make a Thunk implementation that generated standalone InputSections
>> rather than adding as patches to existing InputSections.
>>
>> The disadvantage with extra flexibility is that it increases the
>> amount of opportunities for both implementers and users to make
>> mistakes, and it makes some implementation details more complicated.
>> Where we would have been able to guarantee a single OutputSection, we
>> may have many clumps of InputSections distributed across several
>> OutputSections. In some cases it is user error to split InputSections
>> apart as they need to be contiguous, which requites diagnostics, and
>> in some cases algorithms need to be careful, for example in embedded
>> systems it is not always appropriate to string merge between
>> OutputSections as these OutputSections may not exist in memory on the
>> at the same time (Overlays).
>>
>> Personally I think the additional flexibility is worth it.
>>
>> [*] Mapping symbols identify ranges of ARM code ($a), Thumb code ($t)
>> and literal data ($d). It would be great to add these to Thunks and
>> PLT entries as this would improve disassembly.
>>
>> On 19 October 2016 at 10:37, Eugene Leviant via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > I would suggest converting only part of linker generated sections to
>> > input sections to reduce amount of code changes.
>> > For example it's unlikely that SymbolTableSection or
>> > StringTableSection would ever require such treatment, so why
>> > converting them to input sections?
>
>
> I think if the scheme works for all sections, and if it doesn't
> unnecessarily complicate the code, we should convert all sections to input
> sections in order to keep the architecture simple. "The linker creates its
> own sections as input sections" is easier to explain/understand than "... as
> either input sections or output sections."
>
>> >
>> > 2016-10-19 11:03 GMT+03:00 George Rimar <grimar at accesssoftek.com>:
>> >>>This idea popped up in the review thread for
>> >>> https://reviews.llvm.org/D25627.
>> >>
>> >>>
>> >>>Problem:
>> >>>
>> >>>Currently, LLD creates special sections that are not just
>> >>> concatenations of
>> >>> input sections but need link-time data generation, such as .got, .plt,
>> >>> interp, .mips.options, >etc., as output sections. We have
>> >>> OutputSectionBase
>> >>> subclasses (e.g. GotSection, PltSection, etc.) to create data. Even
>> >>> though
>> >>> this scheme works in most cases, >there are a few situations that
>> >>> doesn't
>> >>> work well as you may have noticed. Here are a issues.
>> >>>
>> >>  >- You cannot mix special sections with other types of sections.
>> >>>
>> >>>  For example, using linker scripts, you can instruct the linker put
>> >>> mergeable sections and non-mergeable sections into the same output
>> >>> section.
>> >>> Such script makes >sense. However, LLD cannot handle such script
>> >>> because
>> >>> string merging is the special mergeable output section's feature. The
>> >>> output
>> >>> section doesn't know how to >handle other types of sections, so you
>> >>> cannot
>> >>> feed non-mergeable sections to a mergeable output section.
>> >>>
>> >>> - It cannot handle linker scripts like this as pointed by Eugene.
>> >>>
>> >>>  .got { *(.got.plt) *(.got) }
>> >>>
>> >>>   In our current architecture, .got section is an output section, so
>> >>> it
>> >>> cannot be added to other output section. There's no clean way to
>> >>> handle this
>> >>> linker script.
>> >>>
>> >>>Proposal:
>> >>>
>> >>>Here's my idea: how about creating all special sections as input
>> >>> sections
>> >>> instead of output sections?
>> >>>
>> >>>GotSection, PltSection, etc. will be subclasses of InputSection that
>> >>> don't
>> >>> have corresponding input files. What they will do remain the same.
>> >>> They will
>> >>> be added to >OutputSections just like other regular sections are
>> >>> added. I
>> >>> think we could simplify OutputSection a lot -- OutputSection will
>> >>> probably
>> >>> become a dumb container >that just concatenates all input sections.
>> >>>
>> >>>This approach would solve the problems described above. Now that we
>> >>> create
>> >>> .got as an special input section with ".got" as a name, so they can
>> >>> naturally be added >to any output section. String merging occurs
>> >>> inside a
>> >>> special mergeable input section, so they can be added to any section,
>> >>> too.
>> >>>
>> >>>So, I think by moving the implementations from OutputSection to
>> >>> InputSection, we can solve many problems. I do not think of any
>> >>> obvious
>> >>> problem with the >approach.
>> >>>
>> >>>What do you think?
>> >>
>> >> For me that sounds as interesting idea. My consern and guess that
>> >> amount of
>> >> code changes can be really large for that.
>> >> But generally I so not see real problems with this approach too.
>> >>
>> >> George.
>> >>
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>