Re: [gold commit] Fix problems with --dynamic-list option.

[Cary Coutant <ccoutant at google dot com>]

>> 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).

-cary