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

[Rui Ueyama via llvm-commits]

Now that George committed a fix for the bug that we are producing the bogus
file, so I think we want to revert this.

On Thu, Mar 17, 2016 at 8:13 PM, Ed Maste via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> 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.
> _______________________________________________
> 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/20160318/632b05ad/attachment.html>