Re: [PATCH] Put GNU_UNIQUE symbols into the dynamic section.

[Cary Coutant <ccoutant at gmail dot com>]

>    // If exporting all symbols or building a shared library,
> +  // or the symbol should be globally unique (GNU_UNIQUE),
>    // and the symbol is defined in a regular object and is
>    // externally visible, we need to add it.
> -  if ((parameters->options().export_dynamic() || parameters->options().shared())
> +  if ((parameters->options().export_dynamic() || parameters->options().shared() ||
> +       this->binding() == elfcpp::STB_GNU_UNIQUE)

The '||' operator should be at the beginning of the second line, lined
up under the 'p'. I'd also suggest splitting at both '||' operators,
for better readability.

Gold has a --no-gnu-unique option that converts STB_GNU_UNIQUE to
STB_GLOBAL while writing the dynamic symbol table. This was to work
around an issue with older dynamic loaders. I'm not sure what the
right behavior would be in the presence of that option -- export the
symbol anyway, or treat it as not-gnu-unique? If the latter, you'll
need to change this to:

  if ((parameters->options().export_dynamic()
       || parameters->options().shared()
       || (parameters->options().gnu_unique() && this->binding() ==
elfcpp::STB_GNU_UNIQUE))

My initial opinion is that there's no reason to force the symbol to be
exported if we're not going to mark it as GNU_UNIQUE, but I'm open to
arguments the other way.

It's also possible that --no-gnu-unique might be ready for
deprecation. Paul, do you have an opinion on that?

-cary