This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gcc-4.0.2: supporting -fvisibility for solaris ld

The recommended way to build gcc-4.0.2 on Solaris 10 x86 is to use the
binutils assembler and the solaris linker:

This works, as long as you suppress HAVE_GAS_COMDAT_GROUP ( see ) but the resulting
compiler does not support -fvisibility in any useful way, because the
solaris linker fails the configure check "checking linker for .hidden
support". The solaris linker does support .hidden though, so I am
looking into adding support for -fvisibility with solaris ld. I have
run into a problem, and I have a few questions.

If, for purposes of experimentation, I hack up configure so that it
sets HAVE_GAS_HIDDEN unconditionally, then make bootstrap succeeds,
and I can in fact use the visibility flags, pragmas, and attributes.
The resulting binaries show that symbols are correctly marked as LOCL
and GLOB in accordance with the visibility selections. So far, so

The problems start when I specify an -march argument in 32 bit mode.
If when compiling I pass -march=pentium, -march=pentium2, etc., I get
errors when trying to link more than one object file:

ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined:
        (file thunk32.o type=FUNC; file visibility32.o type=FUNC);

If I look at the assembly listings in thunk32.s and visibility32.s I
see the same listing that defines __i686.get_pc_thunk.bx in both

        .section        .gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits
.globl __i686.get_pc_thunk.bx
        .hidden __i686.get_pc_thunk.bx
        .type   __i686.get_pc_thunk.bx, @function
        movl    (%esp), %ebx

In these same object files, there are other .gnu.linkonce sections,
but the symbol is always marked .weak:

        .weak   _ZTV3Foo
        .section        .gnu.linkonce.d._ZTV3Foo,"aw",@progbits
        .align 8
        .type   _ZTV3Foo, @object
        .size   _ZTV3Foo, 16
        .long   0

So unlike all of the other .gnu.linkonce sections, where the contained
symbol is marked as .weak, __i686.get_pc_thunk.bx is marked .globl. To
my mind, the linker is right to complain when linking two objects
containing that definition.

With COMDAT group support disabled, is it true that part of gcc's
implementation of .gnu.linkonce semantics is to make the symbol in the
.gnu.linkonce section weak?

If so, should symbols like __i686.get_pc_thunk.* also be weak in this
instance, instead of global? If not, would someone please explain why

Would enabling COMDAT group support (the sun linker does support it)
remove this problem?

If so, can anyone see a way around the fact that the solaris linker
considers relocations against discarded symbols a fatal error, and it
is nearly inevitable that when using COMDAT groups there will be
relocations in the .eh_frame or debug_info sections against
.gnu.linkonce sections that will be discarded?

Sorry for the length, or if this is all somehow way off base; I'm new
to gcc internals...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]