From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9019 invoked by alias); 3 Feb 2014 18:13:35 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 9010 invoked by uid 89); 3 Feb 2014 18:13:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: multi.imgtec.com Received: from multi.imgtec.com (HELO multi.imgtec.com) (194.200.65.239) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 03 Feb 2014 18:13:33 +0000 From: Jack Carter To: "H.J. Lu" CC: "binutils@sourceware.org" Subject: RE: [MIPS] Is it legal for the assembler to generate more than 64K sections? Date: Mon, 03 Feb 2014 18:13:00 -0000 Message-ID: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6F2AA2@BADAG02.ba.imgtec.org> References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6F2880@BADAG02.ba.imgtec.org>, In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-Processed: 7_3_0_01192__2014_02_03_18_13_30 X-SW-Source: 2014-02/txt/msg00017.txt.bz2 ________________________________________ >From: H.J. Lu [hjl.tools@gmail.com] >Sent: Friday, January 31, 2014 4:25 PM >To: Jack Carter >Cc: binutils@sourceware.org >Subject: Re: [MIPS] Is it legal for the assembler to generate more than 64= K sections? > >On Fri, Jan 31, 2014 at 3:22 PM, Jack Carter wrot= e: >> My question is: shouldn't the assembler barf and if not, shouldn't the c= onsuming 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 ho= le 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 in= fo is bad. Readelf also consumes the object without complaint except is a l= ittle 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, o= 32, 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. How is this fine if the ABI it is reading into only supports 16 bits? typedef struct { 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 */ } Elf32_Ehdr; /* Symbol table entry. */ typedef struct { 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 */ } Elf32_Sym; Does this mean everywhere in binutils and glibc for MIPS that there is a da= ta 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 M= IPS ABI? Thanks, Jack > >> The test case is c++ with macros and templates: llvm/tools/clang/unittes= ts/Tooling/RecursiveASTVisitorTest.cpp. >> I'm not really interested why so many sections got created, but in why t= he gnu assembler would allow this and why readobj and or the linker don't a= lert 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 nec= essary patches to at least catch the section issue since I have a ready tes= t case. >> >> Thanks, >> >> Jack > > > >-- >H.J.