This is the mail archive of the
mailing list for the binutils project.
RE: [MIPS] Is it legal for the assembler to generate more than 64K sections?
- From: Jack Carter <Jack dot Carter at imgtec dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 3 Feb 2014 18:12:47 +0000
- Subject: RE: [MIPS] Is it legal for the assembler to generate more than 64K sections?
- Authentication-results: sourceware.org; auth=none
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6F2880 at BADAG02 dot ba dot imgtec dot org>,<CAMe9rOrtyAQYyzRx4AbcmtCSKMr-rzjUcHEHsCAm60j_PhP5Uw at mail dot gmail dot com>
>From: H.J. Lu [firstname.lastname@example.org]
>Sent: Friday, January 31, 2014 4:25 PM
>To: Jack Carter
>Subject: Re: [MIPS] Is it legal for the assembler to generate more than 64K sections?
>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
How is this fine if the ABI it is reading into only supports 16 bits?
unsigned char e_ident[EI_NIDENT]; /* Magic number and other info */
Elf32_Half e_type; /* Object file type */
Elf32_Half e_machine; /* Architecture */
Elf32_Word e_version; /* Object file version */
Elf32_Addr e_entry; /* Entry point virtual address */
Elf32_Off e_phoff; /* Program header table file offset */
Elf32_Off e_shoff; /* Section header table file offset */
Elf32_Word e_flags; /* Processor-specific flags */
Elf32_Half e_ehsize; /* ELF header size in bytes */
Elf32_Half e_phentsize; /* Program header table entry size */
Elf32_Half e_phnum; /* Program header table entry count */
Elf32_Half e_shentsize; /* Section header table entry size */
Elf32_Half e_shnum; /* Section header table entry count */
Elf32_Half e_shstrndx; /* Section header string table index */
/* Symbol table entry. */
Elf32_Word st_name; /* Symbol name (string tbl index) */
Elf32_Addr st_value; /* Symbol value */
Elf32_Word st_size; /* Symbol size */
unsigned char st_info; /* Symbol type and binding */
unsigned char st_other; /* Symbol visibility */
Elf32_Section st_shndx; /* Section index */
Does this mean everywhere in binutils and glibc for MIPS that there is a data structure that could store a section index that it needs to be increased to 32 bits?
Or does it mean that even though the gABI seems to handled 32 bit sections, for MIPS we should reject that amount because it will be illegal for the MIPS ABI?
>> 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.