This is the mail archive of the
mailing list for the binutils project.
Re: [gold patch] Fix incremental update problems with shared objects and versioned symbols
- From: Cary Coutant <ccoutant at google dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Mon, 10 Oct 2011 13:40:38 -0700
- Subject: Re: [gold patch] Fix incremental update problems with shared objects and versioned symbols
- References: <CAHACq4pQg5mGr76Z6vk3z_VN+45G8H_18e4a4Y39kkxGVKodqw@mail.gmail.com> <email@example.com>
>> 2011-09-27 ?Cary Coutant ?<firstname.lastname@example.org>
>> ? ? ? * gold/incremental.cc (Sized_incremental_binary::do_process_got_plt):
>> ? ? ? Check for NULL.
>> ? ? ? * gold/symtab.cc (Symbol_table::add_from_relobj): Ignore version
>> ? ? ? symbols during incremental update.
>> ? ? ? (Symbol_table::add_from_dynobj): Likewise.
> This is OK.
I've been thinking about how to fix this right, and I'm tending
towards the belief that it's fine as is. In order to track the
versions of defined symbols, I don't think it would be enough to use
the version sections in the a.out, because those won't necessarily
contain versions for all the symbols defined in shared libraries.
Therefore, I'd have to record version definitions for the symbols in
the incremental link info for each shared library. Once a full link
has resolved all the symbols, though, the only danger in ignoring
versions in subsequent incremental updates is that a changed file
might explicitly reference a different version of a library entry
point. I wonder what the likelihood is of that, and whether there
might be easier ways of detecting that and forcing a fallback to a
full link in that case.
What do you think?