Re: [MIPS] Is it legal for the assembler to generate more than 64K sections?

["H.J. Lu" <hjl.tools@gmail.com>]

On Fri, Jan 31, 2014 at 3:22 PM, Jack Carter <Jack.Carter@imgtec.com> wrote:
> My question is: shouldn't the assembler barf and if not, shouldn't the consuming elf readers scream?
>
> I am debugging a test case where it looks like there are 77298 sections, but there is only 2 bytes to hold the section count in the ehdr and symbol header. Both relocations and the sections themselves seem to be able to hole 32 bits of section count.
>
> The assembler produces the .o without complaint. The linker consumes the object without complaint, but sometimes barfs because relocation/symbol info is bad. Readelf also consumes the object without complaint except is a little wierd on the section count:
>
> % readelf -h bad.o
> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>   Class:                             ELF32
>   Data:                              2's complement, little endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              REL (Relocatable file)
>   Machine:                           MIPS R3000
>   Version:                           0x1
>   Entry point address:               0x0
>   Start of program headers:          0 (bytes into file)
>   Start of section headers:          22654764 (bytes into file)
>   Flags:                             0x70001007, noreorder, pic, cpic, o32, mips32r2
>   Size of this header:               52 (bytes)
>   Size of program headers:           0 (bytes)
>   Number of program headers:         0
>   Size of section headers:           40 (bytes)
>   Number of section headers:         0 (77298)
>   Section header string table index: 65535 (77294)
>
> My home grown elfdump refused to read the object in the first place.

This is perfectly fine with the current gABI which supports >64K
sections.  You need to find out why MIPS backend can't handle
it properly.  Check how SHN_LORESERVE and SHN_XINDEX
are handled.

> The test case is c++ with macros and templates: llvm/tools/clang/unittests/Tooling/RecursiveASTVisitorTest.cpp.
> I'm not really interested why so many sections got created, but in why the gnu assembler would allow this and why readobj and or the linker don't alert me to the fact things are not well in ELF land.
>
> If this is a bug, I can submit it as bug and try to come up with the necessary patches to at least catch the section issue since I have a ready test case.
>
> Thanks,
>
> Jack



-- 
H.J.