Re: Bfd/binutils inconsistency re: *UND* and *ABS* and relocs against dummy (STT_NOTYPE) symbol entries in elf symbol tables!?

[Ian Lance Taylor <ian at wasabisystems dot com>]

"Dave Korn" <dk@artimi.com> writes:

>  -  ELF symbol tables all begin with a dummy entry, followed by a symbol for
> the filename, followed by section symbols, and then general symbols.  (I
> don't know if this format is mandated or merely conventional or even just
> coincidental.)

The dummy symbol is required.  All local symbols are required to
precede all global symbols, and the sh_info field of the .symtab
section gives the symbol index of the first global symbol.  The other
aspects you mention are merely the way the GNU tools work, and are
essentially coincidental.

>  -  It's ambiguous what to do when you encounter a reloc against symbol #0,
> which is (at least on-disk) the dummy entry of type STT_NOTYPE.

It's not ambiguous from the standard point of view.  Symbol #0 is
required to be a symbol with value zero.  A reloc against that symbol
is well-defined.

>  -  Sometimes (objdump) this dummy entry is discarded when the symbol table
> is read; then a reloc against symbol #0 actually refers to the first real
> entry in the symbol table, which corresponds to the filename symbol.

Sounds buggy.

>  -  Sometimes (readelf, ld), the dummy entry is kept in the table; then a
> reloc against symbol #0 is treated as against none/invalid symbol.

Sounds correct.

>  -  The code that is emitting these relocs against symbol #0 *thinks* it's
> emitting  a reloc against the *ABS* section.  As bfd appears to use the
> filename symbol internally to represent the *ABS* section, and the filename
> symbol is always zeroth in the table (once the dummy STT_NOTYPE symbol has
> been discarded), this works, but I don't know if that's just a coincidence
> or not: i.e., is the deliberate and approved way of issuing a reloc against
> an *ABS* target to base it against the file symbol, or is that just a
> private convention of bfd, or just a quirk of the particular backend
> (dlx-elf32) that I'm working on, such that emitting relocs against it does
> *work*, but you aren't actually supposed to according to the ELF standard?
> I've found comments in other target backends which say things like 
> 	  /* r_symndx will be zero only for relocs against symbols
> 	     from removed linkonce sections, or sections discarded by
> 	     a linker script.  */
> which make me wonder if the assembler is issuing these relocs incorrectly in
> the first place.

The comment is false in general.  It may be true for a particular
backend--a particular backend may happen to never emit relocations
against symbol zero.

>  -  XXXX_relocate_section gets really confused by this whole situation,
> because it's generally written like this:
> 
> 	[...loop across all relocs....]
>       r_symndx = ELF32_R_SYM (rel->r_info);
>       if (r_symndx < symtab_hdr->sh_info)
> 	{
> 	  sym = local_syms + r_symndx;
> 	  sec = local_sections[r_symndx];
> 	  sym_name = bfd_elf_local_sym_name (input_bfd, sym);
> 
> 	  relocation = _bfd_elf_rela_local_sym (output_bfd, sym, sec, rel);
> 	}
> 	[...else find out some other way...]
> 
> and if ELF32_R_SYM returns zero, sym ends up pointing to the dummy
> STT_NOTYPE entry and sec to the *UND* section.  That's not right.

I agree.  I believe sec should wind up being set to bfd_abs_sec_ptr.

Ian