From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10792 invoked by alias); 31 Jan 2014 23:23:31 -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 10781 invoked by uid 89); 31 Jan 2014 23:23:30 -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; Fri, 31 Jan 2014 23:23:30 +0000 From: Jack Carter To: "binutils@sourceware.org" Subject: [MIPS] Is it legal for the assembler to generate more than 64K sections? Date: Fri, 31 Jan 2014 23:23:00 -0000 Message-ID: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6F2880@BADAG02.ba.imgtec.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-Processed: 7_3_0_01192__2014_01_31_23_23_26 X-SW-Source: 2014-01/txt/msg00380.txt.bz2 My question is: shouldn't the assembler barf and if not, shouldn't the cons= uming elf readers scream? I am debugging a test case where it looks like there are 77298 sections, bu= t there is only 2 bytes to hold the section count in the ehdr and symbol he= ader. 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 ob= ject without complaint, but sometimes barfs because relocation/symbol info = is bad. Readelf also consumes the object without complaint except is a litt= le 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=20 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.=20 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 aler= t 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 necess= ary patches to at least catch the section issue since I have a ready test c= ase. Thanks, Jack