This is the mail archive of the
mailing list for the binutils project.
Re: [gold commit] Fix problems with --dynamic-list option.
- From: Cary Coutant <ccoutant at google dot com>
- To: Cary Coutant <ccoutant at google dot com>, Binutils <binutils at sourceware dot org>
- Date: Thu, 6 Feb 2014 15:03:27 -0800
- Subject: Re: [gold commit] Fix problems with --dynamic-list option.
- Authentication-results: sourceware.org; auth=none
- References: <20140206020434 dot 09251160AB3 at ccoutant dot mtv dot corp dot google dot com> <20140206223010 dot GD3596 at bubble dot grove dot modra dot org>
>> PR gold/16530 complains that symbols listed in the --dynamic-list script
>> can still be garbage collected. I've fixed this by checking the symbols
>> as they're added to the symbol table. (Unlike the --export-dynamic-symbol
>> option, we can't iterate over the list, because the --dynamic-list script
>> can have wildcards in it.)
> Should --dynamic-list affect garbage collection? If so, what about
> --dynamic-list-cpp-new, --dynamic-list-cpp-new, and --dynamic-list-data?
> I'm thinking the next thing you'll see is a complaint that
> --dynamic-list now unexpectedly prevents garbage collection, for
> someone using a wildcard in their dynamic-list file.
I thought about this, and concluded that --dynamic-list should in fact
prevent garbage collection, because the symbols in that list have been
explicitly called out (even if via wildcard). The other forms of
--dynamic-list-xxx, on the other hand, call for a class of symbol, so
I reasoned that they should only affect what's left after garbage
collection. I could be wrong.
I'm more worried about gold users that have been expecting
--dynamic-list to do the wrong thing. After a bit of archeology, I
found that the initial implementation in gold was done so it could be
used as a file-based version of --export-dynamic-symbol -- i.e., for
executables rather than shared libraries. As a result, its
implementation w.r.t shared libraries was incomplete, and it was
actually possible to use it along with -Bsymbolic, which means that
even though the symbols are all exported and called via the PLT, the
DT_SYMBOLIC flag is set in the dynamic table, and the dynamic loader
is still going to resolve them all within the library. So the old gold
behavior is that --dynamic-list with -Bsymbolic preserved -Bsymbolic
behavior, while simply forcing each symbol in the list to be exported.
I suspect, however, that gold users (at least those within Google)
have been using --dynamic-list on executables, and that anyone using
it while building a shared library would have noticed the difference
between Gnu ld and gold (as PR 13577 did).