<p dir="ltr"><br>
On Feb 23, 2015 12:40 PM, "Shankar Easwaran" <<a href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:<br>
><br>
> On 2/23/2015 10:02 AM, Rafael Espíndola wrote:<br>
>><br>
>> On 22 February 2015 at 19:04, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:<br>
>>><br>
>>> Author: shankare<br>
>>> Date: Sun Feb 22 18:04:49 2015<br>
>>> New Revision: 230194<br>
>>><br>
>>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=230194&view=rev">http://llvm.org/viewvc/llvm-project?rev=230194&view=rev</a><br>
>>> Log:<br>
>>> [ELF] Add .gnu.linkonce support.<br>
>>><br>
>>> When the GNU linker sees two input sections with the same name, and the name<br>
>>> starts with ".gnu.linkonce.", the linker will only keep one copy and discard the<br>
>>> other. Any section whose name starts with “.gnu.linkonce.” is a COMDAT section.<br>
>>><br>
>>> Some architectures like Hexagon use this section to store floating point constants,<br>
>>> that need be deduped.<br>
>><br>
>> Why not use SHF_MERGE sections?<br>
><br>
> I have seen SHF_MERGE only works with readonly, I may be wrong.</p>
<p dir="ltr">How can you merge read write data?</p>
<p dir="ltr">> SHF_MERGE does not work as there are specific signatures that are used with .gnu.linkonce to store hot code too (.gnu.linkonce.t) and we also use TLS floating point data in gnu linkonce too.</p>
<p dir="ltr">Code isn't a floating point constant :-)</p>
<p dir="ltr">What is the issue with shf_merge and tls?</p>
<p dir="ltr">Cheers,<br>
Rafael </p>