
<html><head></head><body>It still looks like a stretch, no?<br>

<br>

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.<br>

<br>

Cheers,<br>

Rafael<br><br><div class="gmail_quote">On March 29, 2017 11:27:37 AM EDT, George Rimar via llvm-commits <llvm-commits@lists.llvm.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">.gnu.hash happen to contain only 32-bit integers for 32-bit arch,<br />but the section contents are not uniform array members, so setting<br />entsize doesn't make much sense. This behavior seems to have been<br />blindly copied from GNU linkers.<br /></blockquote><br />I do not thing it was blindly copied, it was explicitly mentioned in oracle blog that:<br /><br />"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."<br />(<a href="https://blogs.oracle.com/ali/entry/gnu_hash_elf_sections">https://blogs.oracle.com/ali/entry/gnu_hash_elf_sections</a>)<br /><br />George.<br /><hr /><br />llvm-commits mailing list<br />llvm-commits@lists.llvm.org<br /><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br /></pre></blockquote></div><br>

-- <br>

Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>