This is the mail archive of the binutils@sourceware.org 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: [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


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