[lld] r205163 - [core] support .gnu.linkonce sections

Shankar Easwaran shankare at codeaurora.org
Mon Mar 31 11:42:38 PDT 2014


On 3/31/2014 1:31 PM, Rui Ueyama wrote:
> On Mon, Mar 31, 2014 at 11:21 AM, Shankar Easwaran 
> <shankare at codeaurora.org <mailto:shankare at codeaurora.org>> wrote:
>
>     On 3/31/2014 1:02 PM, Rui Ueyama wrote:
>>
>>     I did not simply push back this patch but also pointed out some
>>     issues that were in your patch with a suggestion.
>>
>>     My suggestion was to merge it with COMDAT group section if they
>>     share the same semantics. If COMDAT groups and .gnu.linkonce
>>     sections need to be distinguished only to detect collisions of
>>     different types, i'd be great if we can compartment that detail
>>     in a small piece of code in Resolver, rather than spreading
>>     typeGroupComdat||typeGnuLinkOnce at every if's. Can't you use
>>     name prefix ".gnu.linkonce" to detect one section is a
>>     .gnu.linkonce section? If not, can't you add a new attribute for it?
>>
>     I dont want to make a comparison on section names in the resolver.
>
>
> Why? It might not feel very clean, but thinking that .gnu.linkonce is 
> a kind of reserved name, and this is for compatibility with old tools 
> that still produces .gnu.linkonce instead of COMDAT group sections, 
> that may be good enough.
As you have already mentioned its not very clean, other reasons that I 
have are as below :-

a) Increase in lld IR's file size (when a file has a lot of 
.gnu.linkonce sections)
b) attribute scale across formats
c) formats that dont have sections can use this functionality, if there 
is a need.
d) simple reason, we have only attributes to identify things in lld with 
the atom model.
e) much faster than comparing every group atom if its part of a 
.gnu.linkonce section
f) less cleaner without attributes

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-commits/attachments/20140331/a401d0c2/attachment.html>


More information about the llvm-commits mailing list