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

Shankar Easwaran shankare at codeaurora.org
Mon Mar 31 12:02:35 PDT 2014


On 3/31/2014 1:40 PM, Rui Ueyama wrote:
> On Mon, Mar 31, 2014 at 11:31 AM, Rui Ueyama <ruiu at google.com 
> <mailto:ruiu at google.com>> 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.
>
>
> Or, alternatively, I'd add isComdatGroup (non-virtual) function to 
> defined atom to check if it's a COMDAT group or .gnu.linkonce and use 
> it in if's.

In my opinion, Attributes are only added to Atoms, if there is no clean 
way to support functionality without that addition.

Also, there is no need to make this a separate attribute of an Atom, as 
there is only one flavor that uses linkonce ie, .gnu.linkonce.

For Gnu linkonce, setting the contentType is one of the solutions that I 
can think of, 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-commits/attachments/20140331/caf15fc4/attachment.html>


More information about the llvm-commits mailing list