[Bug gold/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 --- Comment #4 from zenith432 at users dot sourceforge.net --- There's an ambiguity in ANSI C about this. From C11 Section 6.9.2 External object definitions 1 If the declaration of an identifier for an object has file scope and an initializer, the declaration is an external definition for the identifier. 2 A declaration of an identifier for an object that has file scope without an initializer, and without a storage-class specifier or with the storage-class specifier static, constitutes a tentative definition. If a translation unit contains one or more tentative definitions for an identifier, and the translation unit contains no external definition for that identifier, then the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type as of the end of the translation unit, with an initializer equal to 0. And then there's Annex J (Informative) Portability issues J.5.11 Multiple external definitions 1 There may be more than one external definition for the identifier of an object, with or without the explicit use of the keyword extern; if the definitions disagree, or more than one is initialized, the behavior is undefined (6.9.2). So the normative 6.9.2 decrees things to be the way described in Comment 2, but then J.5.11 which is only informative and is about portability issues talks about "definitions disagree, or more than one is initialized" - but according to 6.9.2 they're always initialized. So when they wrote J.5.11 they still had in mind the concept of a tentative definition which is uninitialized. You could argue there's no contradiction, but there's no reason to include the phrase "or more than one is initialized" unless the concept of tentative definition still has any impact. Anyways, the choice of whether to use ANSI C or GNU extensions is given to the compiler - what business does the linker have enforcing ANSI C after a choice was made during compile-time to use extensions? There are no ld options to choose whether to enforce ANSI C or not. The linker is not even restricted to C. Or C++ (which has ODR). Fortran has common blocks. ld supports Fortran, doesn't it? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 Cary Coutant changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #5 from Cary Coutant --- The point about Fortran is a fair one, and, I think, compelling. If a .o contains a named common block, and an archive contains a BLOCK DATA, the linker should include the BLOCK DATA. Compiling with gcc -fno-common does provide a way to get the strict ANSI C behavior, and requires no extra linker support. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 zenith432 at users dot sourceforge.net changed: What|Removed |Added CC||zenith432 at users dot sourceforge ||.net --- Comment #6 from zenith432 at users dot sourceforge.net --- (In reply to Alexander Monakov from comment #1) > I think the behavior exhibited by gold is expected given absence of > --whole-archive, and it's ld.bfd that is doing something not mandated by the > ELF spec here. So the ELF spec does lay down an undecisive law for dynamic linking of common. Couldn't find anything comparable for static linking of archives. http://www.sco.com/developers/gabi/latest/ch4.symtab.html section 4.20 When the dynamic linker encounters a reference to a symbol that resolves to a definition of type STT_COMMON, it may (but is not required to) change its symbol resolution rules as follows: instead of binding the reference to the first symbol found with the given name, the dynamic linker searches for the first symbol with that name with type other than STT_COMMON. If no such symbol is found, it looks for the STT_COMMON definition of that name that has the largest size. In the prior section 4.19 there is something about weak symbols which have similar search conundrums When the link editor combines several relocatable object files, it does not allow multiple definitions of STB_GLOBAL symbols with the same name. On the other hand, if a defined global symbol exists, the appearance of a weak symbol with the same name will not cause an error. The link editor honors the global definition and ignores the weak ones. Similarly, if a common symbol exists (that is, a symbol whose st_shndx field holds SHN_COMMON), the appearance of a weak symbol with the same name will not cause an error. The link editor honors the common definition and ignores the weak ones. When the link editor searches archive libraries [see ``Archive File'' in Chapter 7], it extracts archive members that contain definitions of undefined global symbols. The member's definition may be either a global or a weak symbol. The link editor does not extract archive members to resolve undefined weak symbols. Unresolved weak symbols have a zero value. The ambiguity I mentioned about ANSI C is resolved by noticing that Annex J.5 is a list of common externsions to C. They are allowed by the STD for portability, but not necessarily conforming. The GCC documentation for -fno-common states = fno-common In C code, this option controls the placement of global variables defined with- out an initializer, known as tentative definitions in the C standard. Tentative definitions are distinct from declarations of a variable with the extern keyword, which do not allocate storage. Unix C compilers have traditionally allocated storage for uninitialized global variables in a common block. This allows the linker to resolve all tentative definitions of the same variable in different compilation units to the same object, or to a non-tentative definition. This is the behavior specified by ‘-fcommon’, and is the default for GCC on most targets. On the other hand, this behavior is not required by ISO C, and on some targets may carry a speed or code size penalty on variable references. The ‘-fno-common’ option specifies that the compiler should instead place unini- tialized global variables in the data section of the object file. This inhibits the merging of tentative definitions by the linker so you get a multiple-definition error if the same variable is defined in more than one compilation unit. Compiling with ‘-fno-common’ is useful on targets for which it provides better performance, or if you wish to verify that the program will work on other systems that always treat uninitialized variable definitions this way. = So the GCC doc claims that the common-based implementation of tentative definitions is simply "not required by ISO C", but the last sentence is a tacit admission that it is in fact non-conforming to ISO C - non-portable. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 zenith432 at users dot sourceforge.net changed: What|Removed |Added CC|zenith432 at users dot sourceforge | |.net| -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23409] Shared libraries created with duplicate _end, _edata and __bss_start symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=23409 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1b115e8e0e051d65d0747f0a8a84eb6453866729 commit 1b115e8e0e051d65d0747f0a8a84eb6453866729 Author: Cary Coutant Date: Sat Jul 14 12:29:03 2018 -0700 Fix problem causing duplicated linker-generated symbols with versions. When generating _end, _edata, etc. symbols, and a version script provides a version name, and we are linking against another shared library that provides those symbols with a different version, gold ends up trying to resolve the other shared library's symbols to the new definitions, resulting in two copies of each symbol, one as default, and one as non-default. This patch tests for that condition, and ignores the symbols provided by the other shared library. gold/ PR gold/23409 * symtab.cc (Symbol_table::define_special_symbol): Add check for version name on existing symbol. * testsuite/Makefile.am (ver_test_pr23409): New test case. * testsuite/Makefile.in: Regenerate. * testsuite/ver_test_pr23409.sh: New test script. * testsuite/ver_test_pr23409_1.script: New version script. * testsuite/ver_test_pr23409_2.script: New version script. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23409] Shared libraries created with duplicate _end, _edata and __bss_start symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=23409 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.32 --- Comment #2 from Cary Coutant --- Fixed on master. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23397] internal error in emit_relocs_scan gold/reloc.cc:518
https://sourceware.org/bugzilla/show_bug.cgi?id=23397 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1074bc6d41f480e9e7b8f2e68f778225da2559b7 commit 1074bc6d41f480e9e7b8f2e68f778225da2559b7 Author: Cary Coutant Date: Sat Jul 14 11:52:27 2018 -0700 Fix internal error when using --emit-relocs with plugins. When an .eh_frame section has deferred layout because of plugins, gold was neglecting to mark the section as deferred. When we later processed the corresponding relocation section, we were then ignoring it, causing the internal error later on in the link. gold/ PR gold/23397 * object.cc (Sized_relobj_file::do_layout): Mark section as deferred. * testsuite/Makefile.am (plugin_test_1): Add --emit-relocs option to existing test case. * testsuite/Makefile.in: Regenerate. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23397] internal error in emit_relocs_scan gold/reloc.cc:518
https://sourceware.org/bugzilla/show_bug.cgi?id=23397 Cary Coutant changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.32 --- Comment #2 from Cary Coutant --- This should be fixed now. I didn't verify that all the failures are fixed. Please reopen if any failures remain -- that would likely be a separate bug. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23413] New: Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 Bug ID: 23413 Summary: Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: dilyan.palauzov at aegee dot org CC: ian at airs dot com Target Milestone: --- Created attachment 11128 --> https://sourceware.org/bugzilla/attachment.cgi?id=11128&action=edit Output of make when gold is the default linker while building gcc 7.3 Building gcc-7.3.1+ (88621ae81401f55d7a8c2c7ce1d6bf2b8d91ce1e) with export CONFIG_SITE="a" gcc.git/configure --enable-threads=posix --enable-nls --disable-multilib --enable-interpreter --with-system-zlib --enable-libgcj-multifile --enable-languages=all --enable-targets=all --with-system-unwind --without-x --with-linker-hash-style=gnu --enable-shared --with-build-config=bootstrap-lto\ bootstrap-O3 && make and having as default linker GNU gold (GNU Binutils 2.31.51.20180711) 1.16 fails at stage 2 with the attached text. With GNU ld (GNU Binutils) 2.31.51.20180711 as default linker the build continues beyond this step (enters stage 3 and I have not waited until the build ends). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23413] Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 --- Comment #1 from dilyan.palauzov at aegee dot org --- binutils is linked with export CONFIG_SITE="a" export CFLAGS="-O3 -pipe" export CXXFLAGS="-O3 -pipe" export LDFLAGS="-Wl,-O1,-s -fuse-ld=gold" /git/binutils-gdb/configure --enable-threads --with-system-zlib --with-system-readline --with-python=/usr/local/bin/python3 --enable-compressed-debug-sections=gold,ld --enable-gold=default make -j2 && make install && make distclean && rm -rf b* e* g* i* l* o* r* sim Why gold says /usr/local/x86_64-pc-linux-gnu/bin/ld: error: cannot find -lisl /usr/local/x86_64-pc-linux-gnu/bin/ld: error: cannot find -lmpc /usr/local/x86_64-pc-linux-gnu/bin/ld: error: cannot find -lmpfr /usr/local/x86_64-pc-linux-gnu/bin/ld: error: cannot find -lgmp /usr/local/x86_64-pc-linux-gnu/bin/ld: error: cannot find -lz but ld.bfd continues despite this, I cannot say. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23413] Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 --- Comment #2 from dilyan.palauzov at aegee dot org --- In fact I have libisl, libmpc -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23413] Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 --- Comment #3 from dilyan.palauzov at aegee dot org --- I have libisl and libmpc only in /usr/local/lib, libgmp in /usr/local/lib and /usr/lib/x86_64-linux-gnu , and libz in /usr/local/lib and /lib/x86_64-linux-gnu. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23413] Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 --- Comment #4 from Cary Coutant --- Gold is not configured by default to search /usr/local/lib. To configure gold to search /usr/local/lib, use configure ... --with-lib-path=/lib:/usr/lib:/usr/local/lib Or you can configure GCC to add "-L /usr/local/lib" to the linker options. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23413] Builing gcc --with-build-config=bootstrap-lto\ bootstrap-O3 and gold fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23413 --- Comment #5 from dilyan.palauzov at aegee dot org --- Please align the default settings of ld.gold to match those of ld.bfd. The defaults of ld.gold and ld.bdf in this regard (defaults for -L) shall be the same, except there are complelling reasons and it is insisted, that the defaults are different. Having different defaults leads to linkers which are not interchangable and to lost time for the users, which is not in the common interest. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
