This is the mail archive of the binutils@sources.redhat.com 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]

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


 
> -----Original Message-----
> From: Ian Lance Taylor 

  Hi again Ian!

> since the dummy 
> > symbol actually represents an absolute zero, the local_sections[0] 
> > entry corresponding to the local_syms[0] entry for it 
> should point to 
> > ABS, not UND, because that's what section the symbol is 
> actually in.  
> > It's misleading to claim the zero symbol is undefined: it isn't.
> 
> I agree 

  I'm not sure that this always actually is the case, in fact.  See below.

> It's not used in very many places.  It's set up in
> elf_link_input_bfd() in elflink.h.

  And here's the underlying cause of the problem: the if .. elseif ladder
that sets up the section pointers looks like this:

      if (isym->st_shndx == SHN_UNDEF)
	  isec = bfd_und_section_ptr;
      else if (isym->st_shndx < SHN_LORESERVE
        || isym->st_shndx > SHN_HIRESERVE)
	{
	  ...details snipped....
	}
      else if (isym->st_shndx == SHN_ABS)
        isec = bfd_abs_section_ptr;
      else if (isym->st_shndx == SHN_COMMON)
	  isec = bfd_com_section_ptr;
      else
	{
	  /* Who knows?  */
	  isec = NULL;
	}

and of course, the dummy symbol has zeros in every field, and SHN_UNDEF==0.
Really, this code should know not to interpret any fields in the dummy
symbol.  There's already a test just below this code that avoids outputting
the dummy symbol; I'll combine that test with setting the local sections
array entry and move it in front of the if..elseif ladder.

>  It should be easy to 
> double-check the uses other than relocation_section to make 
> sure.  They should all be in that file, I think.

  I can see it potentially impacting on the order in which section symbols
get emitted, and perhaps other things too.  I haven't finished looking
through the code to see what else it might perhaps affect.

  There also seems to be a bit of an ambiguity: after relocate_section, we
come to emit relocs, and I found a bit of code there that says:

		  r_symndx = ELF_R_SYM (irela->r_info);
		  if (r_symndx == STN_UNDEF)
		    continue;

and of course, STN_UNDEF == 0 as well: here's include/elf/common.h:

#define STN_UNDEF	0		/* Undefined symbol index */

  So now I'm worried that there really genuinely is an ambiguity in bfd: a
zero in the symbol index field of a reloc has two distinct meanings;
sometimes it means that the symbol is undefined, but other times it means
that the symbol referred to is the absolute zero symbol.  Ouch.  I'm going
to plough on and see how things turn out, though, anyway.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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