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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jack Carter <Jack.Carter@imgtec.com> writes:
> ________________________________________
>>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
>> 64K sections?
>>
>>On Fri, Jan 31, 2014 at 3:22 PM, Jack Carter <Jack.Carter@imgtec.com> 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?

See:

    http://www.sco.com/developers/gabi/latest/ch4.eheader.html

specifically:

e_shnum
    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.)

What's the problem you're seeing exactly?  I wasn't sure from your
original message.

Thanks,
Richard