[PATCH] D27415: [ELF] - Replace MergeOutputSection with synthetic input section MergeSection.

George Rimar via llvm-commits llvm-commits at lists.llvm.org
Sat Jan 28 00:17:12 PST 2017


>>I am trying to solve issue I am demonstrating at https://reviews.llvm.org/D29217 page.
>>It has:
>>
>>  .section .aaa.1,"a"
>>  .byte 11
>>  .section .aaa.2,"a"
>>  .byte 22
>>
>>  .section .bbb.1,"aMS", at progbits,1
>>  .asciz "foo"
>>  .section .bbb.2,"aMS", at progbits,1
>>  .asciz "foo"
>>
>>  .section .ccc.1,"a"
>>  .byte 33
>>  .section .ccc.2,"a"
>>  .byte 44
>>
>>It has also symbols assignments to A and B that should mark the start/end of .ccc :
>>
>>  .rodata : { *(.aaa.*) *(.bbb.*) A = .; *(.ccc.*) B = .; }
>>
>>**1. LLD currently (clean head revision) do: **
>>
>>It creates 2 output .rodata sections:
>>.rodata (.aaa.1 .aaa.2 .ccc.1 .ccc.2)
>>.rodata (.bbb.1 .bbb.2)
>
>OK, so my understanding is this.
>
>Assume you have four mergeable string input sections .foo.1, .foo.2, .bar.1 and .bar.2, where .foo.{1,2} are writable but .bar.{1,2} are not. Also assume you have this >linker script.
>
>  .rodata : { *(.foo.*) *(.bar.*); }
>
>LLD currently creates two .rodata sections for those inputs. One for .foo.{1,2} and the other for .bar.{1,2}. This is because mergeable sections are merged based on >section attributes.
>
>Is this correct? What do you think is a correct behavior?

If you look at my testcase D29217, you'll see it is not issue I am trying to solve.
Also, looking at the writable-merge.s? testcase, I think your example is unreal, we do not support writable merge sections.?

I am trying to solve situation when mergeable and non-mergeable sections are mixed inside single command, what results in a two different output section and breaks symbol assigning logic.
Clean solution here is to create synthetic mergeable sections, right ? So I think correct behavior for my testcase it to create single output section.

George.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170128/6315ceeb/attachment.html>


More information about the llvm-commits mailing list