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

[James Henderson via llvm-commits]

Whilst I don't know of any specific examples, I could imagine a case where
an external analysis tool (like objdump etc) doesn't know what a section
represents, but still could nicely display a hex dump divided up into
regular lumps of entsize size. As such, I agree that keeping sh_entsize set
for those it makes sense for is the right thing to do.

On 3 April 2017 at 20:43, Rui Ueyama via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> Some sections has redundant sh_entsize value indeed, but because the spec
> requires it to be set to some value if a section contains fixed-size
> entries, I don't want to always set it to 0.
>
> On Mon, Apr 3, 2017 at 1:09 AM, George Rimar <grimar at accesssoftek.com>
> wrote:
>
>> >You still need to propagate sh_entsize for some sections for the -r
>> option.
>>
>> ​​I was mean linker generated sections, like symtab, where sh_entsize itself
>> does not look usefull anyways,
>> ​because content is always about symbols, whic​h depends on target size
>> and LE/BE kind.
>> ​In that case setting sh_entsize seems to be excessive.
>> ​
>> George.
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170404/fb79b9db/attachment.html>