From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30874 invoked by alias); 20 Jan 2011 14:23:39 -0000 Received: (qmail 30853 invoked by uid 22791); 20 Jan 2011 14:23:37 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Jan 2011 14:23:32 +0000 From: "ro at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/47378] New: ld warning linking with libgo.so: relocation bound to a symbol with STV_PROTECTED visibility X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ro at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 20 Jan 2011 14:43:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg02054.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47378 Summary: ld warning linking with libgo.so: relocation bound to a symbol with STV_PROTECTED visibility Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned@gcc.gnu.org ReportedBy: ro@gcc.gnu.org CC: iant@google.com Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* While linking some libgo testcases when using Sun ld, I get linker warnings like 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 The symbol goes into the .data.rel.ro section $ elfdump -s .libs/libgo.so |grep __go_tdn_libgo_reflect.reflect.Type [6203] 0x00472720 0x00000028 OBJT GLOB P 1 .data.rel.ro __go_tdn_libgo_reflect.reflect.Type [52554] 0x00472720 0x00000028 OBJT GLOB P 0 .data.rel.ro __go_tdn_libgo_reflect.reflect.Type which is read-write $ elfdump -c -N .data.rel.ro .libs/libgo.so Section Header[33]: sh_name: .data.rel.ro sh_addr: 0x46c8a0 sh_flags: [ SHF_WRITE SHF_ALLOC ] sh_size: 0x14dc8 sh_type: [ SHT_PROGBITS ] sh_offset: 0x45c8a0 sh_entsize: 0 sh_link: 0 sh_info: 0 sh_addralign: 0x20 This section goes into a read-write segment: $ elfdump --segments .libs/libgo.so File: .libs/libgo.so Elf file type is DYN (Shared object file) Entry point 0x0 There are 5 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00000000 0x00000000 0x3c5840 0x3c5840 R E 0x10000 LOAD 0x3c5840 0x003d5840 0x00000000 0x1222b4 0x13918c RWE 0x10000 DYNAMIC 0x0000d4 0x000000d4 0x00000000 0x00178 0x00000 RWE 0 TLS 0x4e7af0 0x004f7af0 0x00000000 0x00004 0x00008 RW 0x4 LOOS+464e550 0x00024c 0x0000024c 0x00000000 0x0a94c 0x0a94c R 0x4 Section to Segment mapping: Segment Sections... 00 .dynamic .eh_frame_hdr .hash .SUNW_ldynsym .dynsym .dynstr .SUNW_version .SUNW_versym .SUNW_dynsymsort .SUNW_dyntlssort .SUNW_reloc .rel.plt .plt .text .init .fini .text.unlikely .rodata .rodata.str1.1 .rodata.str1.4 .rodata.cst4 .rodata.cst8 .rodata.cst16 01 .got .eh_frame .gcc_except_table .data .bssf .picdata .ctors .dtors .jcr .data.rel.ro .data.rel.ro.local .data.rel.local .data.rel .tdata .bss 02 03 .tdata .tbss 04 .eh_frame_hdr It's exactly the same with gld 2.21 instead: the symbol goes into .data.rel.ro, the section is read-write, and the section goes into a read-write segment: $ readelf --segments .libs/libgo.so File: .libs/libgo.so Elf file type is DYN (Shared object file) Entry point 0x1c4380 There are 5 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00000000 0x00000000 0x3aacb4 0x3aacb4 R E 0x1000 LOAD 0x3aacb4 0x003abcb4 0x003abcb4 0x11fe50 0x136d6c RW 0x1000 DYNAMIC 0x47e3e8 0x0047f3e8 0x0047f3e8 0x000e8 0x000e8 RW 0x4 TLS 0x3e966c 0x003ea66c 0x003ea66c 0x00004 0x00008 R 0x4 Section to Segment mapping: Segment Sections... 00 .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr 01 .eh_frame .gcc_except_table .tdata .ctors .dtors .jcr .data.rel.ro .dynamic .got .data .bss 02 .dynamic 03 .tdata .tbss 04 .eh_frame_hdr although (unlike Sun ld, that doesn't care about section names, only access rights) gld knows about .data.rel.ro. This should be avoided somehow since, given the information it has, Sun ld is perfectly right to warn about the relocation. See also http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01358.html