This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH][RFC] Explicitly set ELF symbol size to zero for undefined symbols -- libbfd, gold
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. 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.
Ian