This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
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.
Created an attachment (id=8287) [edit] 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
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?
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.
Huh, foo is defined in a different TU (module in elf terms). Where in the elf documention says this what you said should happen?
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.
Is this a regression?
__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.
(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.
My guess is this is an ELF only bug. I don't beleive ppc-darwin is an ELF target.
.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.
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.
The first attempt is at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01835.html
(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
(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... :>
... maybe, while you are at it, you can check whether the patch for 19664 alone is ok with current mainline?!? Thanks in advance.
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.
(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 (...)
Bug 21382 is a duplicate of bug 19664, which also requires the libstdc++ change.
Created an attachment (id=10416) [edit] 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.
Created an attachment (id=10421) [edit] patch for current 4.1 branch. I would love to see a ppc-linux part for this patch.
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
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.
(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.
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?
The problem is with .libs/main_skel.o. Why don't you show us the relocation and definition in .libs/main_skel.o?
Created an attachment (id=12714) [edit] main_skel.o
(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.
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.
I am not sure if my patch handles hidden data reference properly. Should I work on that?
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.
(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
(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.
The updated patch is posted at http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00361.html
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?
(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.
(In reply to comment #32) > The hidden definition in main_skel.o is ignored due to COMDAT group. could you fill PR?
The updated patch is at http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00397.html
(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
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
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.
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.
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.
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.
This patch http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00594.html doesn't cause any regressions on AIX nor HPUX: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00595.html http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00754.html
This version is OK for mainline.
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
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.
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
This is fixed on the mainline. It is maybe worth backporting as it cannot be worked around.
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
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!
(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
Reassigning since H.J. fixed the bug.
(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.