[lld] r263664 - [ELF] SHF_MERGE section with 0 entsize is not fatal

[Ed Maste via llvm-commits]

On 17 March 2016 at 15:01, Sean Silva <chisophugis at gmail.com> wrote:
>
> In the spec it says:
>
> http://www.sco.com/developers/gabi/latest/ch4.sheader.html
> sh_entsizeSome sections hold a table of fixed-size entries, such as a symbol
> table. For such a section, this member gives the size in bytes of each
> entry. The member contains 0 if the section does not hold a table of
> fixed-size entries.
>
> Isn't `sh_entsize == 0` what would be set for a mergeable string table?

It seems not -- Ian Lance Taylor described sh_entsize for SHF_STRINGS
in https://sourceware.org/ml/binutils/2012-11/msg00145.html:
| sh_entsize tells the linker the size of a character in a string. This
| permits the linker to correctly handle strings represented in, e.g.,
| UTF-16 or UCS-2.

So in practice we'd usually see sh_entsize=1 for SHF_STRINGS sections.

> Why haven't we run into this before?

In fact we have, it's just that having this cause an issue requires
using lld -r to produce a relocatable object that has a SHF_MERGE
section, and then feeding that back into lld as input. Until we had -r
support there was no opportunity to observe it.

Also it turns out the FreeBSD amd64 userland build doesn't use lld -r
in this way. I only observed it when starting to try lld in the the
FreeBSD/i386 build, which uses -r to create the C runtime objects like
crt1.o.