llvm dev - Mar 2014 - [LLVMdev] [lld] supporting gnu linkonce sections in core linking

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 ?

Thanks

Shankar Easwaran

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140331/75a944d4/attachment.html>

Have you found .gnu.linkonce in the in the wild? What is producing them?

On 31 March 2014 13:26, Shankar Easwaran <shankare at codeaurora.org>
wrote:
> 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 ?
>
> Thanks
>
> Shankar Easwaran
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by
> the Linux Foundation
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

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 :)

.gnu.linkonce.<datatype>.<signature>

Sometimes gcc emits the datatype for no reason, so you cannot assume 
that there is a datatype always.

Thanks

Shankar Easwaran


On 3/31/2014 6:42 PM, Rafael Espíndola wrote:
> Have you found .gnu.linkonce in the in the wild? What is producing them?
>
> On 31 March 2014 13:26, Shankar Easwaran <shankare at codeaurora.org>
wrote:
>> 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 ?
>>
>> Thanks
>>
>> Shankar Easwaran
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by
>> the Linux Foundation
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

I committed a change with the solution that I suggested below as part of 
r205280.

Thanks

Shankar Easwaran

On 3/31/2014 12:26 PM, Shankar Easwaran wrote:
> 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 ?
>
> Thanks
>
> Shankar Easwaran
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by the Linux Foundation
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140401/939cfac6/attachment.html>