On Friday, September 23, 2005, at 08:31 AM, Andrew Morrow wrote:
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
files:
.section
.gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits
.globl __i686.get_pc_thunk.bx
.hidden __i686.get_pc_thunk.bx
I think this is a port problem. Step the code that does:
DECL_ONE_ONLY (decl) = 1;
(*targetm.asm_out.unique_section) (decl, 0);
named_section (decl, NULL, 0);
(*targetm.asm_out.globalize_label) (asm_out_file, name);
fputs ("\t.hidden\t", asm_out_file);
from i386.c:ix86_file_end. For group COMDAT, the label will (should)
be external and everybody else should cope with that. For
_gnu_linkonce type things, it will (should) be weak.
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.
Correct.
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?
Yes, gcc should make it weak, one way, or another.
If so, should symbols like __i686.get_pc_thunk.* also be weak in this
instance, instead of global?
Yes.
Would enabling COMDAT group support (the sun linker does support it)
remove this problem?
It should, unless the SUN linker is broken and assuming no other issues
in the compiler that prevent it from working.
