Bug in >64k-section ELF handling when linking (with -r)

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

This is just a heads-up for now.  Using top-of-the-tree; updated
2002-11-01 10:35:55 (am).

With a certain collection of objects, (>200M), there are
actually >64k sections around.  (Yes: gcc -ffunction-sections
-fdata-sections.)  When linking these objects relative (-r),
elf_link_flush_output_syms is called from
elflink.h:elf_link_output_sym:~5955 because finfo->symbuf_count
>= finfo->symbuf_size.  At that point, finfo->symshndxbuf !=
NULL, but elf_tdata(finfo->output_bfd)->symtab_shndx_hdr does
not hold valid data.  Note the sh_offset field.  With $ holding
elf_tdata(finfo->output_bfd)->symtab_shndx_hdr for the code at
5994:

(gdb) p *$
$103 = {sh_name = 1838678, sh_type = 0, sh_flags = 0, sh_addr = 0,
sh_size = 0, sh_entsize = 0, sh_link = 69182, sh_info = 0, 
sh_offset = -1, sh_addralign = 0, bfd_section = 0x0, contents = 0x0}

Consequently, the code conditioned by finfo->symshndxbuf != NULL
at ~5994 calls bfd_seek with an incorrect file position, which
returns false, so the link fails.

It's easy to believe that the >64k-sections changes misses
something to correctly cope with elf_link_flush_output_syms
being called when just flushing the buffer (i.e. other than for
final output).  This is my current assumption.  I'll also have
to check why the symbol buffer gets full (i.e. it seems the
maximum number of symbols is incorrectly computed).  This call
is in the middle of the final link.

More later.  Clues welcome.  (I'll even write a test-case for
this bug.  I guess I'll generate the source in the test. ;-)

brgds, H-P