[PATCH] D23713: [ELF] - Fix for PR26968 - i386 lld produces incorrect fatal error "SHF_MERGE section size must be a multiple of sh_entsize"
George Rimar via llvm-commits
llvm-commits at lists.llvm.org
Fri Aug 19 15:05:51 PDT 2016
grimar added inline comments.
================
Comment at: ELF/InputFiles.cpp:188
@@ +187,3 @@
+
+ // In a FreeBSD/i386 world many objects have SHF_MERGE with sh_entsize == 0.
+ if (!EntSize && Config->EMachine == EM_386)
----------------
ruiu wrote:
> emaste wrote:
> > This is no longer true; the objects with `sh_entsize == 0` were due to a bug with lld -r that has since been fixed. So we no longer encounter this issue on FreeBSD/i386. Thus, this issue comes down to a question of what should lld do if it encounters atypical / unusual input.
> >
> > From http://www.sco.com/developers/gabi/1998-04-29/ch4.sheader.html, sh_entsize
> > > contains 0 if the section does not hold a table of fixed-size entries.
> > https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/ggdlu/index.html suggests that mergeable string sections may have `sh_entsize == 0`.
> >
> > In my opinion restoring rL263664 is reasonable; objects with `SHF_MERGE` and `sh_entsize == 0` are not invalid, and the linker is free to just avoid the merge optimization in this case.
> >
> It sounds like
>
> SHF_STRINGS sections: sh_entsize of 0 is valid and should be treated as if 1.
> non-SHF_STRINGS sections: sh_entsize of 0 is invalid (?) and should be treated as non-mergeable sections.
So issue just no longer exist for FreeBSD. I assumed it is still a problem for BSD because it is not very clear from PR page, and so if it is not anymore, do we really need to do something ? Probably there are no such objects in real world ?
https://reviews.llvm.org/D23713
More information about the llvm-commits
mailing list