[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