[lld] r278555 - [ELF] - Do not use mergeable sections when LS is used.

[Rafael Espíndola via llvm-commits]

On 26 August 2016 at 03:57, George Rimar <grimar at accesssoftek.com> wrote:
> These sections are:
>
> [ 6] .rodata           PROGBITS         ffffffff80c87c8c  00c86c8c
>      00000000000e6e4d  0000000000000001 AMS       0     0     1
> [ 7] .rodata           PROGBITS         ffffffff80d6eae0  00d6dae0
>      0000000000246f00  0000000000000000   A       0     0     32
> [ 8] .rodata           PROGBITS         ffffffff80fb59e0  00fb49e0
>      00000000000001f0  0000000000000010  AM       0     0     16
> [ 9] .rodata           PROGBITS         ffffffff80fb5bd0  00fb4bd0
>      00000000000002a0  0000000000000004 AMS       0     0     16
> [10] .rodata           PROGBITS         ffffffff80fb5e70  00fb4e70
>      0000000000000108  0000000000000008  AM       0     0     8
> [11] .rodata           PROGBITS         ffffffff80fb5f78  00fb4f78
>      000000000000000c  0000000000000004 AMS       0     0     4
> [12] .rodata           PROGBITS         ffffffff80fb5f88  00fb4f88
>      0000000000001158  0000000000000001 AMS       0     0     8

Do you know which files they come from?

>> * Still creating multiple sections if one in SHF_MERGE and another is not.
> Problem of this solution is that it is confusing. For example script has
> SIZEOF command which should return the size of output section.
> It is not clear how it should work then. Also imagine something like:
>
> .rodata 0x12345 : { *(.rodata) }
>
> This way we can't create 2 sections at the same VA. I can imaging
> other confusing examples.
> Currently we create one output section from single description and
> that makes logic to be pretty understandable. I would try not to break it
> until other acceptable solutions are possible.

Yes, linker script are fundamentally buggy in that they require elf
sections to be handled by name.

I don't expect things like the above to be common for mergeable
sections, but maybe it is probably better to not just ignore it.

I think what gold does is to have sub-sections, so that, for example,
all 4 byte mergeable sections are together in a subsection. I don't
think that the complication of inventing invisible subsections is
worth it.

>> * Allow adding a merge input section to a regular output section. That
> way at least we disable the merging only if mismatched flags are found
> and only for that section.
>
> This probably can work. I`ll try to implement the patch for that.

Awesome. Even better if it can print a warning along the lines of
"contents of section not merged" :-)

Thanks,
Rafael