Hi Nick, Bigcheese,
I wanted to add support to support .gnu.linkonce sections in the resolver.
About .gnu.linkonce sections
.gnu.linkonce sections were primarily present in ELF that was used in a way to model COMDAT in early ELF implementations.
We have seen usecases of .gnu.linkonce sections used in various object files(mainly libc), and I think its much needed to support this style in lld as well.
a solution to support .gnu.linkonce in lld
I was thinking of adding a typeGnuLinkOnce and special case it in the Resolver.
Differences between .gnu.linkonce and COMDAT
The only thing that I see a difference between gnu linkonce sections and COMDAT is to raise an error when there is a similar looking section with section groups.
Do you see any better design solutions here ?
Have you found .gnu.linkonce in the in the wild? What is producing them?
On Hexagon, clang still generates sections when constants need to be found in the small data section or the quick data section.
With assembly the below syntax that tries to set a constant to a register produces a .gnu.linkonce section.
r1:0 = CONST64(#200)
$ readelf -S -W main.o | grep gnu
[ 5] .gnu.linkonce.l8.CONST_00000000000000C8 PROGBITS 00000000 000148 000008 00 WA 0 0 8
May be MIPS also might generate these kind of sections in the field.
You might already know this, but for the current discussion, below is the semantics, found from a gnu bug
Sometimes gcc emits the datatype for no reason, so you cannot assume that there is a datatype always.
I committed a change with the solution that I suggested below as part of r205280.