Re: [build] Support libgo on Solaris 2

[Ian Lance Taylor <ian at airs dot com>]

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

>>>> * libgo make check results are not too bad either.  I've manually
>>>>   cleaned the output for two issues: the echo -n stuff above and ld
>>>>   warnings:
>>>>
>>>> asn1 ld: warning: relocation warning: R_386_COPY: file /vol/gcc/obj/gcc-4.6.0-20101223/11-gcc-go/i386-pc-solaris2.11/libgo/.libs/libgo.so: symbol __go_tdn_libgo_reflect.reflect.Type: relocation bound to a symbol with STV_PROTECTED visibility
>>>>
>>>>   I still need to look into them.
>>>
>>> The symbol should be in the read-only data section.  I'm not sure why
>>> the linker is creating a COPY reloc for it.
>>
>> It isn't:
>>
>> $ elfdump -s .libs/libgo.so|grep __go_tdn_libgo_reflect.reflect.Type
>>     [6196]  0x004974e0 0x00000028  OBJT GLOB  P    1 .data.rel.ro   __go_tdn_libgo_reflect.reflect.Type
>>    [45868]  0x004974e0 0x00000028  OBJT GLOB  P    0 .data.rel.ro   __go_tdn_libgo_reflect.reflect.Type
>> $ elfdump -c -N .data.rel.ro .libs/libgo.so
>>
>> Section Header[29]:  sh_name: .data.rel.ro
>>     sh_addr:      0x491660        sh_flags:   [ SHF_WRITE SHF_ALLOC ]
>>     sh_size:      0x14dc8         sh_type:    [ SHT_PROGBITS ]
>>     sh_offset:    0x481660        sh_entsize: 0
>>     sh_link:      0               sh_info:    0
>>     sh_addralign: 0x20      
>>
>> I'll have a look why not.  It turns out that the issue exists with both
>> Sun as and gas when used together with Sun ld, while gas/gld is fine.
>> Thinks look exactly the same with gas/gld, though, there's just no
>> warning.
>
> I've investigated further, but to no avail: without -fPIC, the variable
> goes into .rodata and all is fine.  With -fPIC, it goes into
> .data.rel.ro, which despite it's name is read-write.
>
> I've talked to the Sun linker guys, and they explained that ld creates
> the copy relocation to keep the text segment read-only, but warn since
> now there are two copies of a presumably writable data item: the
> variable directly bound inside the shared library with protected
> visibility and the copy in the executable.
>
> I've not been able to construct a minimal testcase: something like
>
> const int cip __attribute__((visibility("protected"))) = 1;
>
> goes into .rodata without and with -fPIC.

OK, it's going into .data.rel.ro because there are relocations in the
initializer, in order to make it position independent.  Thus it goes
into a writable section, which after dynamic relocation is complete can
be made read-only.  Presumably the Sun linker doesn't know about
.data.rel.ro, and so doesn't realize that the variable really is
read-only.  Hence the warning.

Since the variable is read-only, there is no actual problem here.  The
COPY reloc will cause there to be two copies, but that doesn't matter
since the two copies will hold the same values, and the code does not
require that the pointers be the same.  But of course the warning is not
particularly desirable.

I'm declaring these as protected because in the x86_64 small model,
which is the default for gcc, the references in the shared library may
be out of range if they have to refer to the version copied into the
executable.  So I don't think it will work to give them normal
visibility.

A similar issue arises for C++ typeinfo structures.  I think C++ may get
away with it because there are no direct references to the typeinfo
structures, only references from other data structures, which use
64-bit relocations even in the small model.  An approach like that might
work: use variables initialized to the address of the type descriptors,
rather than direct code references.

Or it's also quite possible that I misunderstand something.

Would you mind opening a bug report about this?  The code is fine on
GNU/Linux, and it should run fine even on Solaris, but I guess we should
do something to avoid the linker warnings.

Ian