On Wed, Jun 11, 2014 at 5:01 AM, Rainer Orth
<r...@cebitec.uni-bielefeld.de> wrote:
> Ian Lance Taylor <i...@google.com> writes:
>
>> On Fri, Jun 6, 2014 at 2:12 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de>
>> wrote:
>>> Ian Lance Taylor <i...@google.com> writes:
>>>
>>>> I have committed a patch to libgo to merge from revision
>>>> 18783:00cce3a34d7e of the master library. This revision was committed
>>>> January 7. I picked this revision to merge to because the next revision
>>>> deleted a file that is explicitly merged in by the libgo/merge.sh
>>>> script.
>>>>
>>>> Among other things, this patch changes type descriptors to add a new
>>>> pointer to a zero value. In gccgo this is implemented as a common
>>>> variable, and that requires some changes to the compiler and a small
>>>> change to go-gcc.cc.
>>>
>>> This change introduced many failures on Solaris with /bin/ld, e.g.
>>>
>>> FAIL: go.test/test/bom.go -O (test for excess errors)
>>>
>>> ld: warning: symbol 'go$zerovalue' has differing sizes:
>>> (file bom.o value=0x8; file
>>> /var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libgo/.libs/libgo.so
>>> value=0x800);
>>> bom.o definition taken and updated with larger size
>>
>> Interesting. This is working as intended, except for the warning.
>>
>> go$zerovalue is a common symbol, and the linker is supposed to use the
>> larger version. From the error message I'm guessing the Solaris
>> linker supports this when linking object files, but not when linking
>> an object file against a shared library.
>>
>> I wonder if we could avoid this warning by giving go$zerovalue hidden
>> visibility. That would mean something like this patch.
>>
>> Ian
>>
>> Index: go-gcc.cc
>> ===================================================================
>> --- go-gcc.cc (revision 211315)
>> +++ go-gcc.cc (working copy)
>> @@ -2521,6 +2521,8 @@ Gcc_backend::implicit_variable(const std
>> DECL_COMMON(decl) = 1;
>> TREE_PUBLIC(decl) = 1;
>> gcc_assert(init_tree == NULL_TREE);
>> + DECL_VISIBILITY(decl) = VISIBILITY_HIDDEN;
>> + DECL_VISIBILITY_SPECIFIED(decl) = 1;
>> }
>> else if (is_constant)
>> {
>
> Unfortunately, this doesn't make a difference.
That is peculiar. Can you verify that in libgo.so the symbol
go$zerovalue is marked as hidden? I don't understand why the linker
would say anything about a symbol in a .o file not matching a hidden
symbol in a .so file. That seems like a linker bug, since the symbols
are not being linked together.
> I've now found that ld
> supports
>
> -t
>
> Turns off the warning for multiply-defined tentative
> (common block) data symbols that have different sizes or
> different alignments. This option is equivalent to
> specifying the -z relax=common option.
>
> But I'm reluctant to enable this globally. Since Go uses no specs file,
> support for target-specific (linker) options would have to go into gccgo
> somehow.
Does using that option fix the problem?
The place to add a target-specific linker option is gcc/go/gospec.c.
See, for example, the ways it adds -Wl,-u,pthread_create on some
systems.
Ian
