Re: [PATCH][RFC] Explicitly set ELF symbol size to zero for undefined symbols -- libbfd, gold

[Alan Modra <amodra at bigpond dot net dot au>]

On Sun, Jul 20, 2008 at 10:48:53PM -0700, Ian Lance Taylor wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> 
> > On Mon, Jul 14, 2008 at 11:48:25AM +0100, Simon Baldwin wrote:
> >> This patch explicitly sets the size of undefined ELF symbols to zero for
> >> linker output.
> >> 
> >> Currently, the size of an undefined ELF symbol is copied out of the object
> >> file or DSO that supplies the symbol, on linking.  This size is unreliable,
> >> for example in the case of two DSOs, one linking to the other.  The lower-
> >> level DSO could make an ABI-preserving change that alters the symbol size,
> >> with no hard requirement to rebuild the higher-level DSO.  And if the higher-
> >> level DSO is rebuilt, tools that monitor file checksums will register a
> >> change due to the altered size of the undefined symbol, even though nothing
> >> else about the higher-level DSO has altered.  This can lead to unnecessary
> >> and undesirable rebuild and change cascades in checksum-based systems.
> >> 
> >> Confirmed test parity between pre- and post-patch source trees.
> >> 
> >> Any objections?  Thanks.
> >
> > I feel uncomfortable about this patch, simply because it loses
> > information.  Not that I can think of a solid reason why this would
> > matter.  SHN_COMMON symbols need both size and value, and SHN_UNDEF
> > can't lose a non-zero value (plt symbol hint to ld.so), but SHN_UNDEF
> > size doesn't seem to be that useful.  However, people do weird things
> > with linkers..
> >
> > I'd be much happier if you modified elf_link_add_object_symbols to
> > zero size on reading undefined symbols from dynamic objects.  In fact,
> > there seems to be code there already that would do this.  See
> > "/* Remember the symbol size if it isn't undefined.  */".  Why isn't
> > this code effective?
> 
> Note that that addresses a different issue.

Oh, of course.  Silly me.  Ok, I'm happy if the size is zeroed in
elf_link_output_extsym, but I think it should happen

    case bfd_link_hash_defined:
    case bfd_link_hash_defweak:
      {
	input_sec = h->root.u.def.section;
	if (input_sec->output_section != NULL)
	  {
...
	  }
	else
	  {
	    BFD_ASSERT (input_sec->owner == NULL
			|| (input_sec->owner->flags & DYNAMIC) != 0);
	    sym.st_shndx = SHN_UNDEF;
here.
	    input_sec = bfd_und_section_ptr;
	  }

That way we only zap st_size for the particular case of symbols
defined in dynamic libs.

>  Simon's patch drops the
> size of symbols which are undefined in the executable; they may well
> be defined in the shared library.  As Simon's note suggests, this
> permits bit-for-bit file comparisons of an executable linked against a
> changed shared library, where the shared library changes in a way that
> doesn't affect the ABI.  In particular, when the size of a function
> changes in a shared library, it doesn't actually affect any executable
> linked against that shared library.  Nevertheless, we currently
> generate a different executable, because we record the size of the
> function in the shared library in the executable's symbol table.

-- 
Alan Modra
Australia Development Lab, IBM