[lld] r298934 - Do not set entsize for .gnu.hash.

[Rui Ueyama via llvm-commits]

Yes, that is my point. It doesn't make much sense to set entsize for
sections in which all contents are coincidentally the same size. Setting
entsize makes sense only when contents are uniform same-sized elements.
Setting it to 4 only for 32-bit arch seems a cargo cult.

On Wed, Mar 29, 2017 at 8:35 AM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> It still looks like a stretch, no?
>
> Most things with a entsize have independent items that are x bytes each.
> This section has a complex structure where each member is 32 bits.
>
> Cheers,
> Rafael
>
> On March 29, 2017 11:27:37 AM EDT, George Rimar via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> .gnu.hash happen to contain only 32-bit integers for 32-bit arch,
>>> but the section contents are not uniform array members, so setting
>>> entsize doesn't make much sense. This behavior seems to have been
>>> blindly copied from GNU linkers.
>>>
>>
>> I do not thing it was blindly copied, it was explicitly mentioned in oracle blog that:
>>
>> "The header, hash buckets, and hash chains are always 32-bit words, while the Bloom filter words can be 32 or 64-bit depending on the class of object. This means that ELFCLASS32 GNU_HASH sections consist of only 32-bit words, and therefore have their section header sh_entsize field set to 4. ELFCLASS64 GNU_HASH sections have mixed element size, and therefore set sh_entsize to 0."
>> (https://blogs.oracle.com/ali/entry/gnu_hash_elf_sections)
>>
>> George.
>> ------------------------------
>>
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170329/621b8297/attachment-0001.html>