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

Matt Thomas matt@3am-software.com
Mon Jul 21 16:10:00 GMT 2008


On Jul 21, 2008, at 5:27 AM, Simon Baldwin wrote:

> Alan Modra wrote:
>> ...
>> 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.
>>
>
> Thanks for reviews and suggestion.  Attached is a revised version  
> of the patch, with complementary change to gold.
>
> As before, test parity with pre-patch binutils-2.18.50 snapshot  
> testsuite.
>
> Okay for submit, or not yet?  Thanks.  --S
>
>
> This patch explicitly sets the size of undefined ELF symbols  
> acquired from
> dynamic libraries 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.
>
>
> bfd/ChangeLog:
> 2008-07-21  Simon Baldwin  <simonb@google.com>
>
> 	* elflink.c (elf_link_output_extsym): Set st_size to zero for
> 	undefined symbols from dynamic libraries.
>
> gold/ChangeLog:
> 2008-07-21  Simon Baldwin  <simonb@google.com>
>
> 	* symtab.cc (Symbol_table::sized_write_symbol): Set st_size to
> 	zero for undefined symbols from dynamic libraries.
>
>
> *** ./bfd/elflink.c.orig	Thu Jul 10 15:39:15 2008
> --- ./bfd/elflink.c	Mon Jul 21 12:07:33 2008
> *************** elf_link_output_extsym (struct elf_link_
> *** 8550,8569 ****
> --- 8550,8574 ----
>   				    && !input_sec->gc_mark);
>   		      }
>   		  }
>   	      }
>   	  }
>   	else
>   	  {
>   	    BFD_ASSERT (input_sec->owner == NULL
>   			|| (input_sec->owner->flags & DYNAMIC) != 0);
>   	    sym.st_shndx = SHN_UNDEF;
> +             /* Reset size to zero for undefined symbols.   
> Undefined symbols
> +                may be picked up from shared libraries, and a  
> shared library
> +                can change between here and use with the dynamic  
> loader,
> +                making sizes other than zero invalid.  */
> +             sym.st_size = 0;
>   	    input_sec = bfd_und_section_ptr;
>   	  }
>         }
>         break;
>
>       case bfd_link_hash_common:
>         input_sec = h->root.u.c.p->section;
>         sym.st_shndx = bed->common_section_index (input_sec);
>         sym.st_value = 1 << h->root.u.c.p->alignment_power;
>         break;

This won't solve the problem because the backends can set the section
to SHN_UNDEF in finish_dynamic_symbol (see elf64-x86_64.c).  Hence the
existing comment:

   /* If we are marking the symbol as undefined, and there are no
      non-weak references to this symbol from a regular object, then
      mark the symbol as weak undefined; if there are non-weak
      references, mark the symbol as strong.  We can't do this earlier,
      because it might not be marked as undefined until the
      finish_dynamic_symbol routine gets through with it.  */

If you put a BFD_ASSERT (sym.st_info == 0) inside that if you'll see
a number of assertion failures.



More information about the Binutils mailing list