This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

>From: H.J. Lu []
>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 <> 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.

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 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.
>> Thanks,
>> Jack

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]