[PATCH] D22516: [ELF] - Fix an issue when 2 output sections were created from single declaration in script

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 19 08:13:09 PDT 2016


I don't thin the difference is script versus non-script. gold and bfd
will always ignore some flags when merging sections, gold ignores
SHF_WRITE and SHF_EXECINSTR.

If I try your example with two files, one with

     .section .foo, "aT"

and the other with

  .section .foo, "aw"

gold will create two sections named foo in the output.

The ELF spec explicitly says that "In the first phase, input sections
that match in name, type and attribute flags should be concatenated
into single sections.". Another reason is that it avoid polluting the
flags of other sections. If just a single file needs a rw .text
section, it can have it without causing all other .text section to be
rw.

Have you hit this problem is some existing project?

Cheers,
Rafael




On 19 July 2016 at 10:43, George Rimar <grimar at accesssoftek.com> wrote:
> grimar created this revision.
> grimar added reviewers: ruiu, rafael.
> grimar added subscribers: llvm-commits, grimar, evgeny777.
>
> I noticed that linkerscript-repsection-va.s was wrong:
>
> For single foo entry:
> SECTIONS {.foo : {*(.foo.*)} }
> 2 output sections were created.
>
> I think that is wrong because:
> 1) It is really confusing and complicates the understanding of the script output.
>     I think nobody expects to see multiple output sections for single entry.
> 2) Imagine that some symbols are to be declared:
>  SECTIONS {.foo : {*(.foo.*)} end = .; }
>  what should be the value of end if we have 2 output sections ? Its just confusing.
> 3) gold and ld do not do that.
> 4) It also adds a problem for refactoring of script I do.
>
> Patch fixes that bu combining the flags of sections if scripted layouting is used.
>
>
> https://reviews.llvm.org/D22516
>
> Files:
>   ELF/LinkerScript.cpp
>   ELF/LinkerScript.h
>   ELF/OutputSections.cpp
>   ELF/Writer.cpp
>   test/ELF/linkerscript-repsection-va.s
>


More information about the llvm-commits mailing list