[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:26:04 PST 2017


>>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.

But generally, D27415 now creates synthetic input sections basing on name, flags and alignment of input mergeable sections.
Then created synthetic mergeable sections with different attributes are merged into single output.
That I think is behavior we want when talking about creating synthetic mergeable sections, right ?

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


More information about the llvm-commits mailing list