This is the mail archive of the
mailing list for the binutils project.
More than 65536 sections in an ELF file
- From: Ian Lance Taylor <iant at google dot com>
- To: binutils at sourceware dot org
- Date: Fri, 07 Mar 2008 16:18:36 -0800
- Subject: More than 65536 sections in an ELF file
It seems to me that the support in BFD for ELF files with more than
65536 sections is at least partially wrong. This code in
if (section_number == SHN_LORESERVE)
section_number += SHN_HIRESERVE + 1 - SHN_LORESERVE;
causes a range of section numbers to be skipped. The effect is that
any links to sections with an index larger than SHN_LORESERVE are
incremented. This is effectively undone in elf_object_p in elfcode.h,
which skips that range when building an array.
I just built an ELF object file with 70010 sections. As usual, the
section string table is near the end of the sections, which means
that its index is greater than SHN_LORESERVE == 0xff00.
The ELF standard is pretty clear about the values in the ELF header:
This member holds the number of entries in the section header
table. Thus the product of e_shentsize and e_shnum gives the
section header table's size in bytes. If a file has no section
header table, e_shnum holds the value zero.
If the number of sections is greater than or equal to
SHN_LORESERVE (0xff00), this member has the value zero and the
actual number of section header table entries is contained in the
sh_size field of the section header at index 0. (Otherwise, the
sh_size member of the initial entry contains 0.)
This member holds the section header table index of the entry
associated with the section name string table. If the file has no
section name string table, this member holds the value
SHN_UNDEF. See ``Sections'' and ``String Table'' below for more
If the section name string table section index is greater than or
equal to SHN_LORESERVE (0xff00), this member has the value
SHN_XINDEX (0xffff) and the actual index of the section name
string table section is contained in the sh_link field of the
section header at index 0. (Otherwise, the sh_link member of the
initial entry contains 0.)
So what I expect to see is that the section header at index 0 will
have an sh_size field of 70010 and an sh_link field of 70006. What I
see in fact is an sh_size field of 70010 and an sh_link field of
70262. That is because BFD has added SHN_HIRESERVE - SHN_LORESERVE ==
256 to the section number of the section name string table. 70006 +
256 == 70262.
But this does not follow the ELF standard. And unfortunately there
are probably now a few invalid ELF files out there.