[PATCH] D23924: [ELF] - Linkerscript: allow add MergeInputSection to regular OutputSection.

[Rafael Espíndola via llvm-commits]

Looking at the list George provided in

http://www.writeurl.com/text/qi7t511ci7q2mab6ab9i/7jd6ccrjrzftrv81qazj

I think we have to make one of two hard choices on how we handle this
if we are to claim to properly support linker scripts. What is
happening is that initially the sections do *not* have the same name:

.rodata (No merge) in 1/scsi_all.o
.rodata.str1.1 (SHF_MERGE) in 1/scsi_all.o
.rodata.cst16 (SHF_MERGE) in 1/scsi_all.o

They have different names and each one has a consistent set of flags.
The problem is that it is very common for a linker script to have

.rodata         : { *(.rodata .rodata.*) }

And we are still expected to merge the bits that can be merged. For
example, including the attached file twice in a link causes the string
and the constant 0x42 to be merged. Only 0x43 is duplicated.

One way to fix this is to go back to producing multiple output
sections. It is somewhat confusing, but I don't expect any major
problems with it. We would still be able to handle things like

 .rodata  : {
   foo = .;
  *(.rodata .rodata.*)
  bar = .;
  }

With the VA of foo being in one section and the VA of bar in another.

The other option is to introduce another data structure in the middle
of input and output sections (Chunk?). Input sections are mapped to
chunks of various types (Merge, Eh, Plain) and those are mapped to
output sections which are then just a list of chunks.

It is my impression that the complexity of adding another level is not
worth it and it should be ok to produce multiple output sections when
SHF_MERGE doesn't match.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.s
Type: application/octet-stream
Size: 214 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160829/e15d35f9/attachment.obj>