Bug 20218 - Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol
Summary: Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: H.J. Lu
URL:
Keywords: visibility
Depends on:
Blocks: 19664
  Show dependency treegraph
 
Reported: 2005-02-25 23:00 UTC by H.J. Lu
Modified: 2007-08-27 18:43 UTC (History)
17 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.3.0
Known to fail: 4.0.0 4.1.0 4.2.0
Last reconfirmed: 2006-06-23 04:02:03


Attachments
A testcase (599 bytes, application/octet-stream)
2005-02-25 23:02 UTC, H.J. Lu
Details
Testcase with linker script (389 bytes, application/x-gtar)
2005-12-06 11:15 UTC, Samuel Thibault
Details
patch for current 4.1 branch. (2.32 KB, patch)
2005-12-06 19:26 UTC, Pawel Sikora
Details | Diff
main_skel.o (132.21 KB, application/octet-stream)
2006-11-30 15:16 UTC, Pawel Sikora
Details

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2005-02-25 23:00:26 UTC
When __attribute__ ((visibility ("hidden"))) is used to hide/optimize
a symbol, foo, defined in another .o/archive file, foo isn't marked as
hidden. As the result, I get either runtime or linktime error.
Comment 1 H.J. Lu 2005-02-25 23:02:48 UTC
Created attachment 8287 [details]
A testcase

On ia32

[hjl@gnu hidden]$ make
gcc -O -g   -c -o main.o main.c
gcc -O -g -fPIC   -c -o foo1.o foo1.c
gcc -O -g -fPIC   -c -o bar.o bar.c
gcc -O -g -fPIC   -c -o foo2.o foo2.c
ar rcs libfoo.a foo2.o
gcc -o libbar.so -shared bar.o libfoo.a
gcc -o main main.o foo1.o libbar.so -Wl,-rpath,.
./main
make: *** [all] Error 1

On x86_64 with the older linker:
gcc -B/usr/bin/ -O -g	-c -o main.o main.c
gcc -B/usr/bin/ -O -g -fPIC   -c -o foo1.o foo1.c
gcc -B/usr/bin/ -O -g -fPIC   -c -o bar.o bar.c
gcc -B/usr/bin/ -O -g -fPIC   -c -o foo2.o foo2.c
ar rcs libfoo.a foo2.o
gcc -B/usr/bin/ -o libbar.so -shared bar.o libfoo.a
gcc -B/usr/bin/ -o main main.o foo1.o libbar.so -Wl,-rpath,.
./main
./main: Symbol `foo' causes overflow in R_X86_64_PC32 relocation
./main: Symbol `bar' causes overflow in R_X86_64_PC32 relocation
make: *** [all] Segmentation fault

On x86_64 with the newer linker:

gcc -O -g   -c -o main.o main.c
gcc -O -g -fPIC   -c -o foo1.o foo1.c
gcc -O -g -fPIC   -c -o bar.o bar.c
gcc -O -g -fPIC   -c -o foo2.o foo2.c
ar rcs libfoo.a foo2.o
gcc -o libbar.so -shared bar.o libfoo.a
/usr/local/bin/ld: bar.o: relocation R_X86_64_PC32 against `foo' can not be
used when making a shared object; recompile with -fPIC
/usr/local/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make: *** [libbar.so] Error 1
Comment 2 Andrew Pinski 2005-02-26 01:24:11 UTC
Hmm, from the elf spec:
If different visibility attributes are specified for distinct references to or definitions of a symbol, the 
most constraining visibility attribute must be propagated to the resolving symbol in the linked object. 
The attributes, ordered from least to most constraining, are: STV_PROTECTED, STV_HIDDEN and 
STV_INTERNAL.

So is this really a binutils bug and not a gcc one?
Comment 3 H.J. Lu 2005-02-26 01:42:57 UTC
It is a gcc bug where gcc failed to mark "foo" as hidden with

gcc -O -g -fPIC   -c -o bar.o bar.c

foo is defined in foo2.c.
Comment 4 Andrew Pinski 2005-02-26 02:00:03 UTC
Huh, foo is defined in a different TU (module in elf terms).
Where in the elf documention says this what you said should happen?
Comment 5 H.J. Lu 2005-02-26 02:30:52 UTC
From the elf spec:
If different visibility attributes are specified for distinct references to or
definitions of a symbol, the 
most constraining visibility attribute must be propagated to the resolving
symbol in the linked object. 
The attributes, ordered from least to most constraining, are: STV_PROTECTED,
STV_HIDDEN and 
STV_INTERNAL.

You can't have 2 definitions. The above lines apply to cases where there is
only one definition and others are just references.
Comment 6 Giovanni Bajo 2005-02-27 09:11:10 UTC
Is this a regression?
Comment 7 H.J. Lu 2005-02-27 16:16:12 UTC
__attribute__ ((visibility ("hidden"))) is a new feature. We can define
ASM_OUTPUT_EXTERNAL to make it work properly. I can try to come up with
a patch if everyone agrees is a bug.
Comment 8 Andrew Pinski 2005-02-27 16:19:28 UTC
(In reply to comment #7)
> __attribute__ ((visibility ("hidden"))) is a new feature. We can define
> ASM_OUTPUT_EXTERNAL to make it work properly. I can try to come up with
> a patch if everyone agrees is a bug.
It is not that new.  It was not introduced with 4.0, it has been in gcc since at least Febuary of 2002, so it 
is 3 years old now and nobody noticed this before, I really doubt this is gcc bug as it works correctly on 
ppc-darwin.
Comment 9 H.J. Lu 2005-02-27 16:32:41 UTC
My guess is this is an ELF only bug. I don't beleive ppc-darwin is an ELF
target.
Comment 10 Jakub Jelinek 2005-02-28 14:49:42 UTC
.hidden is intentionally emitted only at the definitions, not for the undefs.
Otherwise a header with 1000 prototypes with __attribute__((visibility
("hidden"))) would result in 1000 STV_HIDDEN SHN_UNDEF symbols, even when they
aren't used at all in the file at all.
Comment 11 H.J. Lu 2005-02-28 15:51:47 UTC
You don't have to emit a STV_HIDDEN SHN_UNDEF symbol unless it is referenced.
On HPUX/ia64, gcc does emit SHN_UNDEF symbols. I hope it only emits referenced
SHN_UNDEF symbols.
Comment 12 H.J. Lu 2005-03-01 16:04:58 UTC
The first attempt is at

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01835.html
Comment 13 Pawel Sikora 2005-05-05 00:31:41 UTC
(In reply to comment #12)  
> The first attempt is at  
>   
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01835.html  
>   
 
patches for pr19664 and 20218 kill gcc bootstrap. gcj fails:  
  
/home/users/builder/rpm/BUILD/gcc-4.0.0/obj-athlon-pld-linux/gcc/gcj  
-B/home/users/builder/rpm/BUILD/gcc-4.0.0/obj-athlon-pld-linux/gcc/  
-B/usr/athlon-pld-linux/bin/ -B/usr/athlon-pld-linux/lib/  
-isystem /usr/athlon-pld-linux/include  
-isystem /usr/athlon-pld-linux/sys-include -ffloat-store  
-fno-omit-frame-pointer -fclasspath=  
-fbootclasspath=(long paths) --encoding=UTF-8  
-Wno-deprecated -O2 -march=athlon -ggdb -fjni -findirect-dispatch  
-c (long list of .class) -fPIC -o .libs/gnu-xml.o  
  
/tmp/B.27ba32/ccv1kDt2jx:0: internal compiler error: in  
lhd_set_decl_assembler_name, at langhooks.c:191  
  
Comment 14 Pawel Sikora 2005-05-05 00:37:31 UTC
(In reply to comment #13) 
> (In reply to comment #12)   
> > The first attempt is at   
> >    
> > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01835.html   
> >    
>   
> patches for pr19664 and 20218 kill gcc bootstrap. gcj fails:   
>    
> /home/users/builder/rpm/BUILD/gcc-4.0.0/obj-athlon-pld-linux/gcc/gcj   
> -B/home/users/builder/rpm/BUILD/gcc-4.0.0/obj-athlon-pld-linux/gcc/   
> -B/usr/athlon-pld-linux/bin/ -B/usr/athlon-pld-linux/lib/   
> -isystem /usr/athlon-pld-linux/include   
> -isystem /usr/athlon-pld-linux/sys-include -ffloat-store   
> -fno-omit-frame-pointer -fclasspath=   
> -fbootclasspath=(long paths) --encoding=UTF-8   
> -Wno-deprecated -O2 -march=athlon -ggdb -fjni -findirect-dispatch   
> -c (long list of .class) -fPIC -o .libs/gnu-xml.o   
>    
> /tmp/B.27ba32/ccv1kDt2jx:0: internal compiler error: in   
> lhd_set_decl_assembler_name, at langhooks.c:191   
>    
 
differ crash on amd64: 
 
stage1/xgcc -Bstage1/ -B/usr/amd64-pld-linux/bin/   -O2 -ggdb 
-fprofile-generate -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros 
-Wold-style-definition     -DHAVE_CONFIG_H    -I. -I. -I../../gcc 
-I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include  -c 
insn-attrtab.c \ 
  -o insn-attrtab.o 
insn-attrtab.c: In function '_GLOBAL__I_0_insn_current_length': 
insn-attrtab.c:64398: internal compiler error: Segmentation fault 
 
and waiting for powerpc core dump... :> 
 
Comment 15 Paolo Carlini 2005-05-05 00:47:45 UTC
... maybe, while you are at it, you can check whether the patch for 19664 alone
is ok with current mainline?!? Thanks in advance.
Comment 16 H.J. Lu 2005-05-05 04:56:31 UTC
I posted an updated patch

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00391.html

It works for me on ia32, ia64 and x86_64.
Comment 17 Pawel Sikora 2005-05-16 01:42:13 UTC
(In reply to comment #16)  
> I posted an updated patch  
>   
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00391.html  
>   
> It works for me on ia32, ia64 and x86_64.  
  
with this version of the patch gcc builds fine on x86_64. 
PR20218 testcase works, PR21382 testcase still fails.  
 
# gcc-4.0.1-20050514 + patches for PR19664,PR20218.  
  
(...)  
.libs/IexBaseExc.o: In function `Iex::BaseExc::~BaseExc()':  
IexBaseExc.cpp:(.text+0x59): undefined reference to  
`std::basic_string<char, std::char_traits<char>,  
 std::allocator<char> >::~basic_string()'  
/usr/bin/ld: .libs/IexBaseExc.o: relocation R_X86_64_PC32 against `_ZNSsD1Ev'  
can not be used when making a shared object; recompile with -fPIC  
/usr/bin/ld: final link failed: Bad value  
collect2: ld returned 1 exit status  
(...)  
 
Comment 18 H.J. Lu 2005-05-16 15:48:07 UTC
Bug 21382 is a duplicate of bug 19664, which also requires the libstdc++
change.
Comment 19 Samuel Thibault 2005-12-06 11:15:27 UTC
Created attachment 10416 [details]
Testcase with linker script

This testcase uses a linker script. The proposed patch
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00391.html
does fix the issue in that case too.
Comment 20 Pawel Sikora 2005-12-06 19:26:45 UTC
Created attachment 10421 [details]
patch for current 4.1 branch.

I would love to see a ppc-linux part for this patch.
Comment 21 Pawel Sikora 2005-12-06 20:55:52 UTC
ok, I hope this ppc-elf-linux fix for pr20218-x86-32_64.patch is correct.
with this both testcases work.

diff -uNrp a/gcc/config/rs6000/linux.h b/gcc/config/rs6000/linux.h
--- a/gcc/config/rs6000/linux.h    2005-11-30 11:15:31.000000000 +0000
+++ b/gcc/config/rs6000/linux.h    2005-12-06 20:02:14.949860336 +0000
@@ -108,7 +108,8 @@
 #define RELOCATABLE_NEEDS_FIXUP \
   (target_flags & target_flags_explicit & MASK_RELOCATABLE)

-#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
+#undef TARGET_ASM_FILE_END
+#define TARGET_ASM_FILE_END rs6000_elf_file_end

 #define TARGET_POSIX_IO

diff -uNrp a/gcc/config/rs6000/linux64.h b/gcc/config/rs6000/linux64.h
--- a/gcc/config/rs6000/linux64.h  2005-11-30 11:15:31.000000000 +0000
+++ b/gcc/config/rs6000/linux64.h  2005-12-06 20:02:03.882542824 +0000
@@ -543,7 +543,8 @@ while (0)
 #undef DRAFT_V4_STRUCT_RET
 #define DRAFT_V4_STRUCT_RET (!TARGET_64BIT)

-#define TARGET_ASM_FILE_END rs6000_elf_end_indicate_exec_stack
+#undef TARGET_ASM_FILE_END
+#define TARGET_ASM_FILE_END rs6000_elf_file_end

 #define TARGET_POSIX_IO

diff -uNrp a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
--- a/gcc/config/rs6000/rs6000.c   2005-11-30 11:15:31.000000000 +0000
+++ b/gcc/config/rs6000/rs6000.c   2005-12-06 20:17:39.014381176 +0000
@@ -611,7 +611,7 @@ static void rs6000_file_start (void);
 static unsigned int rs6000_elf_section_type_flags (tree, const char *, int);
 static void rs6000_elf_asm_out_constructor (rtx, int);
 static void rs6000_elf_asm_out_destructor (rtx, int);
-static void rs6000_elf_end_indicate_exec_stack (void) ATTRIBUTE_UNUSED;
+static void rs6000_elf_file_end (void) ATTRIBUTE_UNUSED;
 static void rs6000_elf_select_section (tree, int, unsigned HOST_WIDE_INT);
 static void rs6000_elf_unique_section (tree, int);
 static void rs6000_elf_select_rtx_section (enum machine_mode, rtx,
@@ -18060,10 +18060,11 @@ rs6000_elf_declare_function_name (FILE *
 }

 static void
-rs6000_elf_end_indicate_exec_stack (void)
+rs6000_elf_file_end (void)
 {
   if (TARGET_32BIT)
     file_end_indicate_exec_stack ();
+  default_elf_asm_file_end ();
 }
 #endif

Comment 22 Andrew Pinski 2006-07-02 02:41:50 UTC
I still say if the definition was not marked as having a visibility, then the code is wrong as someone could mark stuff weirdly.

Now does the other question (since I cannot remember when looking at the elf standard) is that the section about visibility being combined is that about linking or just creating a module.
Comment 23 Jason Merrill 2006-07-02 04:30:40 UTC
(In reply to comment #22)
> I still say if the definition was not marked as having a visibility, then the
> code is wrong as someone could mark stuff weirdly.

Yes, if someone's code marks a function as hidden in a translation unit where it is only called, and not in the TU where it is defined, sounds to me like their code is doing strange and probably broken things.  But that seems to be what the ELF standard requires, and this bug report indicates that several people seem to want the feature.

> Now does the other question (since I cannot remember when looking at the elf
> standard) is that the section about visibility being combined is that about
> linking or just creating a module.

The quotes in other comments make it pretty clear that it's about linking.
Comment 24 Pawel Sikora 2006-11-30 10:47:19 UTC
currently i'm trying to build the kdelibs with gcc42-svn.
my qt and gcc are patched with:

http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/gcc-pr20218.patch?rev=HEAD
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/qt-fvisibility.patch?rev=HEAD

it *worked* fine for gcc41 on x86-64, ix86 and ppc.
now it fails only for gcc42 on x86-64 (ix86 and ppc work).

[~/rpm/BUILD/kdelibs-3.5.5/kcmshell]$ make

/bin/sh ../libtool --silent --tag=CXX   --mode=link "x86_64-pld-linux-g++"  -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -fno-strict-aliasing -fwrapv -march=x86-64 -gdwarf-2 -g2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -fvisibility=hidden -fvisibility-inlines-hidden  -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -Wl,--as-needed  -o libkdeinit_kcmshell.la -rpath /usr/lib64 -no-undefined -avoid-version -L/usr/lib64    main.lo main_skel.lo ../kutils/libkutils.la
/usr/bin/ld: .libs/main_skel.o: relocation R_X86_64_PC32 against `_ZTV9QMemArrayIcE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status


$ readelf -sW /usr/lib64/libqt-mt.so.3.3.7 | grep _ZTV9QMemArrayIcE

19100: 00000000009989c0  56 OBJECT WEAK DEFAULT 18 _ZTV9QMemArrayIcE

$ readelf -sW main_skel.o | grep _ZTV9QMemArrayIcE

   54: 0000000000000000  56 OBJECT WEAK HIDDEN  45 _ZTV9QMemArrayIcE


$ readelf -r main_skel.o|grep _ZTV9QMemArrayIcE
000000000179  003600000002 R_X86_64_PC32     0000000000000000 _ZTV9QMemArrayIcE + c
000000000195  003600000002 R_X86_64_PC32     0000000000000000 _ZTV9QMemArrayIcE + c
000000000003  003600000002 R_X86_64_PC32     0000000000000000 _ZTV9QMemArrayIcE + c
000000000003  003600000002 R_X86_64_PC32     0000000000000000 _ZTV9QMemArrayIcE + c
Relocation section '.rela.data.rel.ro._ZTV9QMemArrayIcE' at offset 0x82010 contains 6 entries:

$ readelf -r /usr/lib64/libqt-mt.so.3.3.7| grep _ZTV9QMemArrayIcE
00000099ad68  4a9c00000001 R_X86_64_64       00000000009989c0 _ZTV9QMemArrayIcE + 10
0000009e30d0  4a9c00000006 R_X86_64_GLOB_DAT 00000000009989c0 _ZTV9QMemArrayIcE + 0

any ideas?
Comment 25 H.J. Lu 2006-11-30 14:44:00 UTC
The problem is with .libs/main_skel.o. Why don't you show us the relocation
and definition in .libs/main_skel.o?
Comment 26 Pawel Sikora 2006-11-30 15:16:03 UTC
Created attachment 12714 [details]
main_skel.o
Comment 27 H.J. Lu 2006-11-30 15:53:42 UTC
(In reply to comment #26)
> Created an attachment (id=12714) [edit]
> main_skel.o
> 

It looks OK. Please provide a complete testcase. It could be a gcc bug,
a linker bug and/or a problem on your system.
Comment 28 Mark Mitchell 2006-12-05 21:13:22 UTC
Jason, are you actively working on this?  (We are motivated to fix the problem, so if you're not working on it, then maybe we can help.)

HJ's patch here:

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00391.html

looks like an OK idea, but:

+  if (TREE_CODE (decl) == FUNCTION_DECL
+      && strstr (name, "__builtin_") == name)

is bogus; this should be checking DECL_IS_BUILTIN, not doing strcmp.

This:

+struct extern_symbol_list *extern_symbol_head;

should be a VEC, not a list.
Comment 29 H.J. Lu 2006-12-05 21:41:27 UTC
I am not sure if my patch handles hidden data reference properly. Should I work
on that?
Comment 30 Mark Mitchell 2006-12-05 21:51:09 UTC
Subject: Re:  Can't use __attribute__ ((visibility ("hidden")))
 to hide a symbol

hjl at lucon dot org wrote:
> ------- Comment #29 from hjl at lucon dot org  2006-12-05 21:41 -------
> I am not sure if my patch handles hidden data reference properly. Should I work
> on that?

Yes, we want to handle both data and functions.

Comment 31 Pawel Sikora 2006-12-05 22:00:55 UTC
(In reply to comment #27)
> (In reply to comment #26)
> > Created an attachment (id=12714) [edit]
> > main_skel.o
> > 
> 
> It looks OK. Please provide a complete testcase. It could be a gcc bug,
> a linker bug and/or a problem on your system.


http://minus.ds14.agh.edu.pl/~pluto/bug.tar.bz2

$ g++ -shared main.o main_skel.o ./libqt-mt.so.3.3.7
/usr/bin/ld: main_skel.o: relocation R_X86_64_PC32 against `_ZTV9QMemArrayIcE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

gcc-4.2.0-0.20061119r118994.1.x86_64
binutils-2.17.50.0.8-1.x86_64
Comment 32 H.J. Lu 2006-12-05 23:33:07 UTC
(In reply to comment #31)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > Created an attachment (id=12714) [edit]
> > > main_skel.o
> > > 
> > 
> > It looks OK. Please provide a complete testcase. It could be a gcc bug,
> > a linker bug and/or a problem on your system.
> 
> 
> http://minus.ds14.agh.edu.pl/~pluto/bug.tar.bz2
> 
> $ g++ -shared main.o main_skel.o ./libqt-mt.so.3.3.7
> /usr/bin/ld: main_skel.o: relocation R_X86_64_PC32 against `_ZTV9QMemArrayIcE'
> can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
> 
> gcc-4.2.0-0.20061119r118994.1.x86_64
> binutils-2.17.50.0.8-1.x86_64
> 
[hjl@gnu-2 bug]$ ld -shared main.o main_skel.o 
ld: main_skel.o: relocation R_X86_64_PC32 against `_ZTV9QMemArrayIcE' can not be used when making a shared object; recompile with -fPIC
ld: final link failed: Bad value
[hjl@gnu-2 bug]$ readelf -a main.o | grep _ZTV9QMemArrayIcE
COMDAT group section [   35] `.group' [_ZTV9QMemArrayIcE] contains 1 sections:
   [  114]   .data.rel.ro._ZTV9QMemArrayIcE
00000000083e  00c300000009 R_X86_64_GOTPCREL 0000000000000000 _ZTV9QMemArrayIcE + fffffffffffffffc
000000000003  00c300000009 R_X86_64_GOTPCREL 0000000000000000 _ZTV9QMemArrayIcE + fffffffffffffffc
000000000003  00c300000009 R_X86_64_GOTPCREL 0000000000000000 _ZTV9QMemArrayIcE + fffffffffffffffc
Relocation section '.rela.data.rel.ro._ZTV9QMemArrayIcE' at offset 0xe75c8 contains 6 entries:
   195: 0000000000000000    56 OBJECT  WEAK   DEFAULT  114 _ZTV9QMemArrayIcE
[hjl@gnu-2 bug]$ readelf -a main_skel.o | grep _ZTV9QMemArrayIcE
  [11] _ZTV9QMemArrayIcE GROUP            0000000000000000  00000090
COMDAT group section [   11] `_ZTV9QMemArrayIcE' [_ZTV9QMemArrayIcE] contains 1 sections:
   [   40]   .data.rel.ro._ZTV9QMemArrayIcE
000000000179  002c00000002 R_X86_64_PC32     0000000000000000 _ZTV9QMemArrayIcE + c
000000000195  002c00000002 R_X86_64_PC32     0000000000000000 _ZTV9QMemArrayIcE + c
000000000003  002c00000002 R_X86_64_PC32     0000000000000000 _ZTV9QMemArrayIcE + c
000000000003  002c00000002 R_X86_64_PC32     0000000000000000 _ZTV9QMemArrayIcE + c
Relocation section '.rela.data.rel.ro._ZTV9QMemArrayIcE' at offset 0x2dd0 contains 6 entries:
    44: 0000000000000000    56 OBJECT  WEAK   HIDDEN   40 _ZTV9QMemArrayIcE
[hjl@gnu-2 bug]$ ld -shared main_skel.o main.o
[hjl@gnu-2 bug]$ 

The hidden definition in main_skel.o is ignored due to COMDAT group.
Comment 33 H.J. Lu 2006-12-05 23:58:33 UTC
The updated patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00361.html
Comment 34 Mark Mitchell 2006-12-06 06:44:43 UTC
Subject: Re:  Can't use __attribute__ ((visibility ("hidden")))
 to hide a symbol

hjl at lucon dot org wrote:
> ------- Comment #33 from hjl at lucon dot org  2006-12-05 23:58 -------
> The updated patch is posted at
> 
> http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00361.html

I don't see anything in your patch to replace the call to
process_pending_assemble_externals that you removed on platforms other
than the ones you changed.

Why can't you just let that function do its job, and emit the visibility
markers at that point?

Comment 35 H.J. Lu 2006-12-06 06:55:48 UTC
(In reply to comment #34)
> Subject: Re:  Can't use __attribute__ ((visibility ("hidden")))
>  to hide a symbol
> 
> hjl at lucon dot org wrote:
> > ------- Comment #33 from hjl at lucon dot org  2006-12-05 23:58 -------
> > The updated patch is posted at
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00361.html
> 
> I don't see anything in your patch to replace the call to
> process_pending_assemble_externals that you removed on platforms other
> than the ones you changed.

I guess I should only remove it for ELF. Can I use

#ifndef OBJECT_FORMAT_ELF
  process_pending_assemble_externals ();
#endif

instead of deleting it?

> 
> Why can't you just let that function do its job, and emit the visibility
> markers at that point?
> 

The problem is we don't know if a symbol is referenced or not at that time.
We don't want to generate

          .hidden foo

just because there is

extern int foo __attribute__ ((visibility ("hidden")));

We should mark it hidden only if it is referenced.

Comment 36 Pawel Sikora 2006-12-06 13:22:04 UTC
(In reply to comment #32)

> The hidden definition in main_skel.o is ignored due to COMDAT group.

could you fill PR?
Comment 37 H.J. Lu 2006-12-06 14:19:15 UTC
The updated patch is at

http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00397.html
Comment 38 H.J. Lu 2006-12-06 14:39:50 UTC
(In reply to comment #36)
> (In reply to comment #32)
> 
> > The hidden definition in main_skel.o is ignored due to COMDAT group.
> 
> could you fill PR?
>

http://sourceware.org/bugzilla/show_bug.cgi?id=3666

Comment 39 Jason Merrill 2006-12-06 19:14:25 UTC
Subject: Re:  Can't use __attribute__ ((visibility ("hidden")))
 to hide a symbol

mmitchel at gcc dot gnu dot org wrote:
> Jason, are you actively working on this?  (We are motivated to fix the problem,
> so if you're not working on it, then maybe we can help.)

Not at the moment, feel free to reassign it.

Jason
Comment 40 Mark Mitchell 2006-12-07 06:35:17 UTC
Subject: Re:  Can't use __attribute__ ((visibility ("hidden")))
 to hide a symbol

hjl at lucon dot org wrote:

> http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00397.html

I'm still not happy with the cgraph_optimize change.  There's no reason
for ELF to be special in this regard.

The problem is that I don't think you can move
process_pending_assemble_externals to the end of the compilation; on
some systems the external declaration needs to appear before any
reference to them.  You could try just removing the call to
process_pending_assemble_externals in cgraph_optimize, since there is
another call at the end of compile_file -- but I'm afraid you'll break
AIX and HP-UX.  You would have to ask people to test on those platforms.

Anyhow, with -fno-unit-at-a-time, we still call ASM_OUTPUT_EXTERNAL as
we process declarations.

I think we should just give up and not worry about whether or not the
functions are referenced.  All that will happen is that we'll get bigger
.o files; the linker will rip all unreferenced functions out anyhow.

Comment 41 jbeulich 2006-12-07 08:15:20 UTC
That's not a good idea, I think. The semantics of how to treat undefined symbols in the symbol table that arten't used in any relocations depend on the OS ABI, not the ELF file format. Non-gld linkers may interpret this as the symbol being required to be pulled in.
Comment 42 Michael Matz 2006-12-07 13:57:09 UTC
I agree with Jan and HJ here.  We must not emit symbols to unreferenced
symbols.  Even the size increase wouldn't be really acceptable.  In a way
ELF _is_ special here, so special handling is completely justified.  In which
way it's handled specially that's not so important.  For instance one could
introduce a new two-pass process_pending_assemble_externals, where on ELF
the first pass would do nothing, and on other platforms whatever is necessary,
and on the last pass [at end of compilation] emit the referenced hidden
symbols on ELF, and do nothing on != ELF.
Comment 43 H.J. Lu 2006-12-07 14:05:23 UTC
I posted the updated patch at

http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00477.html

I have asked Steve and Janis to test it on AIX and HPUX. We are calling
process_pending_assemble_externals in 2 different places anyway. I just
removed the first call. I think we can make it to work for AIX and
HPUX if it isn't working ASIS.
Comment 45 Mark Mitchell 2006-12-12 02:14:51 UTC
This version is OK for mainline.
Comment 46 hjl@gcc.gnu.org 2006-12-12 03:59:06 UTC
Subject: Bug 20218

Author: hjl
Date: Tue Dec 12 03:58:52 2006
New Revision: 119764

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119764
Log:
2006-12-11  H.J. Lu  <hongjiu.lu@intel.com>

	PR middle-end/17982
	PR middle-end/20218
	* cgraphunit.c (cgraph_optimize): Remove call to
	process_pending_assemble_externals.

	* config/elfos.h (ASM_OUTPUT_EXTERNAL): New.

	* config/ia64/hpux.h (TARGET_ASM_FILE_END): Removed.

	* config/ia64/ia64.c (ia64_asm_output_external): Rewritten.
	(ia64_hpux_add_extern_decl): Removed.
	(ia64_hpux_file_end): Likewise.
	(extern_func_list): Likewise.
	(extern_func_head): Likewise.

	* output.h (assemble_external): Update comments.
	(default_elf_asm_output_external): New.
	(maybe_assemble_visibility): New.

	* toplev.c (compile_file): Update comment.

	* varasm.c (assemble_external): Always put it on
	pending_assemble_externals.
	(maybe_assemble_visibility): Make it extern and return int.
	(default_elf_asm_output_external): New.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cgraphunit.c
    trunk/gcc/config/elfos.h
    trunk/gcc/config/ia64/hpux.h
    trunk/gcc/config/ia64/ia64.c
    trunk/gcc/output.h
    trunk/gcc/toplev.c
    trunk/gcc/varasm.c

Comment 47 David Daney 2006-12-13 07:39:27 UTC
This is probably (I have not checked yet as I am still bootstrapping) still a problem on MIPS because my fix for the bootstrap breakage caused by H.J.'s patch removes the generic fix in elfos.h. 
Comment 48 Kazu Hirata 2006-12-16 02:47:40 UTC
Subject: Bug 20218

Author: kazu
Date: Sat Dec 16 02:47:27 2006
New Revision: 119959

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119959
Log:
	Backport from mainline:
	gcc/
	2006-12-11  H.J. Lu  <hongjiu.lu@intel.com>

	PR middle-end/17982
	PR middle-end/20218
	* cgraphunit.c (cgraph_optimize): Remove call to
	process_pending_assemble_externals.

	* config/elfos.h (ASM_OUTPUT_EXTERNAL): New.

	* config/ia64/hpux.h (TARGET_ASM_FILE_END): Removed.

	* config/ia64/ia64.c (ia64_asm_output_external): Rewritten.
	(ia64_hpux_add_extern_decl): Removed.
	(ia64_hpux_file_end): Likewise.
	(extern_func_list): Likewise.
	(extern_func_head): Likewise.

	* output.h (assemble_external): Update comments.
	(default_elf_asm_output_external): New.
	(maybe_assemble_visibility): New.

	* toplev.c (compile_file): Update comment.

	* varasm.c (assemble_external): Always put it on
	pending_assemble_externals.
	(maybe_assemble_visibility): Make it extern and return int.
	(default_elf_asm_output_external): New.

Modified:
    branches/csl/sourcerygxx-4_1/ChangeLog.csl
    branches/csl/sourcerygxx-4_1/gcc/cgraphunit.c
    branches/csl/sourcerygxx-4_1/gcc/config/elfos.h
    branches/csl/sourcerygxx-4_1/gcc/config/ia64/hpux.h
    branches/csl/sourcerygxx-4_1/gcc/config/ia64/ia64.c
    branches/csl/sourcerygxx-4_1/gcc/output.h
    branches/csl/sourcerygxx-4_1/gcc/toplev.c
    branches/csl/sourcerygxx-4_1/gcc/varasm.c

Comment 49 Richard Biener 2007-01-09 12:55:08 UTC
This is fixed on the mainline.  It is maybe worth backporting as it cannot be worked around.
Comment 50 H.J. Lu 2007-01-09 15:11:40 UTC
The (In reply to comment #49)
> This is fixed on the mainline.  It is maybe worth backporting as it cannot be
> worked around.
> 

The backported patches for gcc 4.1/4.2 are at

http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00671.html
Comment 51 John Gaunt (redfive) 2007-01-19 03:25:49 UTC
I believe I'm seeing this bug using a redhat build: gcc4.1.1-1 (shows up all the way through -51). It's only on 64bit FC5, 32bit is okay and am installing FC6 to test. Building XULRunner with --enable-canvas causes the problem, greater description of what I'm seeing is in their bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=367208

Basically a hidden symbol from .o to .a to linking in a .so gives the error listed by the reporter here.

I can't tell from the comments which build will carry this patch. It looks like it would be in 4.1, but the last comment re: backporting makes me wonder. Also I wonder if this patch would have been pulled in to the Redhat build; I'm not familiar with the relationship to the main gcc tree.

Thanks!
Comment 52 Sébastien Bernard 2007-06-13 10:12:35 UTC
(In reply to comment #51)
> I believe I'm seeing this bug using a redhat build: gcc4.1.1-1 (shows up all
> the way through -51). It's only on 64bit FC5, 32bit is okay and am installing
> FC6 to test. Building XULRunner with --enable-canvas causes the problem,
> greater description of what I'm seeing is in their bugzilla:
> https://bugzilla.mozilla.org/show_bug.cgi?id=367208
> 
> Basically a hidden symbol from .o to .a to linking in a .so gives the error
> listed by the reporter here.
> 
> I can't tell from the comments which build will carry this patch. It looks like
> it would be in 4.1, but the last comment re: backporting makes me wonder. Also
> I wonder if this patch would have been pulled in to the Redhat build; I'm not
> familiar with the relationship to the main gcc tree.
> 
> Thanks!
> 

Hi, this backport to gcc-4.1-4.1.2-9 on debian breaks the glibc build on hppa.
The link of librt.so is missing the declaration of symbol __librt_multiple_threads.

By trial and errors, I located the faulty patch (between -8 and -11) and it seems to be that one.

See 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428509

Comment 53 Jason Merrill 2007-08-27 16:32:33 UTC
Reassigning since H.J. fixed the bug.
Comment 54 H.J. Lu 2007-08-27 18:43:24 UTC
(In reply to comment #52)

> 
> Hi, this backport to gcc-4.1-4.1.2-9 on debian breaks the glibc build on hppa.
> The link of librt.so is missing the declaration of symbol
> __librt_multiple_threads.
> 
>

For all the bug reports related to this change I have seen, every single
one is the bug in the source code, not in gcc.  I don't believe this one
is an exception. Please check if you have mismatched symbol visibilities
in your source code.