[PATCH] prevent warnings from -shared-libgcc on mips-irix

[Olivier Hainque]

Hi Richard,

First of all, thanks a lot for your prompt and very constructive
feedback. Much appreciated :)

Richard Sandiford wrote:
> In one way, it seems a shame to compile out support for hidden
> and internal attributes when a common use case works correctly.

> The fact that we're striving so hard to use hidden visibility for
> some things shows that the native linker really does have useful
> support for it, even if that support isn't fully compatible with
> GNU ld's.

 Agreed. And I was actually suprised at GNU ld's behavior the
 first time I came to realize what this was about.
 
> However, I did a bit of digging into the history of all this,
[...]

Thanks for the very insightful journey! I had dug a bit, not as much
as you did, indeed only found pretty old tracks, assumed there might
have been intermediate events I missed or just untracked.

I'm still puzzled by the current operations on "hidden capable"
targets.

In particular, I'm not sure having .hidden on the symbols aimed at
being exposed is intended, especially since they are so only in the
static archive, not the shared library. For instance, on x86_64-linux
with ld 2.17.50:

    $ objdump --sym gcc/libgcc.a | grep __mulsc3
    0000000000000000 g     F .text  00000000000003dd .hidden __mulsc3

    $ objdump --sym gcc/libgcc_s.so | grep __mulsc3
    0000000000003950 g     F .text  00000000000003dd __mulsc3

I thought the general idea would have been to compile with
-fvisibility=hidden so that everything is .hidden by default, then
arrange to have this overriden somehow for the to-be-exposed symbols.

The latter, by way of either some explicit attribute in the source, or
some symbol-to-export-list passing circuitry to the linker, possibly
only in the shared lib case since this is where the hiding makes most
sense IIUC.

AFAICS, exposure in the shared lib case results from compiling without
-fvisibility=hidden, while hiding in the static lib case results from
compiling with -fvis... and not compensating. This really looks
backwards to me.

In any case, as far as Irix is concerned, I think

[...]
> I also agree that leaving it off is the conservative choice.

is a very strong argument.

For instance, we have observed painful to track wrong behavior on
alpha-tru64 out of the explicit hiding of pthread related symbols by

    alpha/t-osf4
    ...
    SHLIB_LINK = $(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) -shared -nodefaultlibs \
	-Wl,-hidden_symbol,pthread\* -Wl,-hidden_symbol,__pthread\* \

These are weak in libgcc, expected to be preempted by real entry
points when linking with -lpthread, but

 "The Tru64 UNIX Object File/Symbol Table Format Specification"

  << 6.3.4.1   Symbol Preemption and Namespace Pollution
     ...
     Hidden symbols do not cause namespace pollution problems and cannot
     be preempted [...]
  >>

so we end up using the fake versions as soon as -shared-libgcc is
involved, triggering concurrent eh misbehavior.

>  Sorry for the wild goose chase.

No problem, that's instructive :-)
 
> I still prefer the new patch to the old one because __gcc_init
> and __gcc_fini should be hidden for GNU ld configurations too.

Fine with me.

> So...

> > 	* config/mips/irix-crti.asm: .hide __gcc_init and __gcc_fini.
[...]
> OK for trunk and all active branches,
 
 Thanks :)

> with two minor comment nits:

> I found the "besides" a bit confusing.  This comment doesn't really
> seem to connect with the earlier one.

The idea was "oh, and we need to do another special thing for the
init/fini related bits here". Nothing of importance and I agree the
comment reads better without (no distraction, more focused).

> How about changing the comment to:
> 
>     /* Explicitly hide crt symbols that would normally be marked with
>        a "hidden" visibility attribute.
> 
>        We have traditionally disabled this attribute for native linker
>        configurations because the native linker's visibility support
>        is not fully-compatible with the GNU linker's.  In particular,
>        the native linker does not pull in archive objects purely to
>        resolve references to the object's hidden symbols.  */
> 
> Hopefully that'll save the next reader from going through the same
> pain you did ;)  Adapt as you see fit.

Unless there's a real intent I missed in having the symbols hidden in
the archives, I'd rather not insist on a linker expected behavior wrt
such libraries. 

The first thing I'd think reading this would be "why do we need such a
behavior from the linker ?", and I'm not convinced by the only answer
I know about today. From the bits of context above, I'm even inclined
to think we actually shouldn't need this behavior :)

Of course, if there's a legitimate need, we'd need to add text about
it, because that is indeed far from obvious to track IMHO.

I agree the initial comment needs rewording, still, to be more general
about which symbols need to be included here and to mention the
conservatism purpose of the current approach, as "traditionally"
suggests.

Would something like

    /* Explicitly hide crt symbols that would normally be marked with
       a "hidden" visibility attribute, which we have traditionally
       disabled for native linker configurations.  */

look apropriate to you ?


Thanks for your feedback,

Olivier