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]

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

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. 

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.



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