Launchpad has imported 15 comments from the remote bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4372.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://documentation.ubuntu.com/launchpad/user/reference/bugs/multi-project-bugs/about-multi-project-bugs/#bugs-in-external-trackers. ------------------------------------------------------------------------ On 2001-09-20T17:26:00+00:00 Carlo Wood wrote: Recently my (test) application started to core dump in __libc_strtol_internal (according to gdb), apparently called from pthread_getspecific. It took me awhile to find out that I had forgotten to add a -lpthread when linking. I considered it a bug that the linker didn't give an error so I tried to write a small test case to reproduce this, but in the test case the linker DID give me `undefined reference to pthread_getspecific'... After a little investigation, I found that the difference between the test case and the problem case could be brought back to the *.ii file: the problem case has included a series of #pragma weak pthread... that caused the linker to think that these functions are present as local functions, while actually it causes a call to address 0x0 (hence the `__libc_strtol_internal' I guess). Because I can not succeed to make a small test case, I'll give results of the my own investigation using the large problem case: ~/c++/libcw_branch-threading/src/libcwd/tests>g++-3.0.1 -DHAVE_CONFIG_H -I. -I- -I../include -DCWDEBUG -g -D_REENTRANT -c hello_world.cc -save-temps -v Reading specs from /usr/local/gcc-3.0.1/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/specs Configured with: /usr/src/gcc/gcc-3.0.1/configure --prefix=/usr/local/gcc-3.0.1 --enable-shared --with-gnu-as --with-gnu-ld --enable-languages=c++ --enable-debug --enable-threads Thread model: posix gcc version 3.0.1 GNU CPP version 3.0.1 (cpplib) (i386 Linux/ELF) ignoring nonexistent directory "/usr/local/gcc-3.0.1/i686-pc-linux-gnu/include" #include "..." search starts here: . #include <...> search starts here: ../include /usr/local/gcc-3.0.1/include/g++-v3 /usr/local/gcc-3.0.1/include/g++-v3/i686-pc-linux-gnu /usr/local/gcc-3.0.1/include/g++-v3/backward /usr/local/include /usr/local/gcc-3.0.1/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/include /usr/include End of search list. /usr/local/gcc-3.0.1/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/cc1plus -fpreprocessed hello_world.ii -quiet -dumpbase hello_world.cc -g -version -o hello_world.s GNU CPP version 3.0.1 (cpplib) (i386 Linux/ELF) GNU C++ version 3.0.1 (i686-pc-linux-gnu) compiled by GNU C version 3.0.1. as --traditional-format -V -Qy -o hello_world.o hello_world.s GNU assembler version 2.11.90.0.8 (i386-redhat-linux) using BFD version 2.11.90.0.8 Next I edit the *.ii file and remove the #pragma weak lines, showing that these are the problem: ~/c++/libcw_branch-threading/src/libcwd/tests>vi hello_world.ii ~/c++/libding/src/libcwd/tests>/usr/local/gcc-3.0.1/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/cc1plus -fpreprocessed hello_world.ii -quiet -dumpbase hello_world.cc -g -version -o hello_world.s GNU CPP version 3.0.1 (cpplib) (i386 Linux/ELF) GNU C++ version 3.0.1 (i686-pc-linux-gnu) compiled by GNU C version 3.0.1. ~/c++/libcw_branch-threading/src/libcwd/tests>as --traditional-format -V -Qy -o hello_world.o hello_world.s GNU assembler version 2.11.90.0.8 (i386-redhat-linux) using BFD version 2.11.90.0.8 ~/c++/libcw_branch-threading/src/libcwd/tests>nm hello_world.o | grep pthread 00000330 t _Z20__gthread_mutex_lockP15pthread_mutex_t 00000360 t _Z22__gthread_mutex_unlockP15pthread_mutex_t U pthread_create U pthread_getspecific U pthread_key_create U pthread_mutex_lock U pthread_mutex_unlock U pthread_once U pthread_setspecific Next, I do this again but now change a pragma into #xxxpragma, getting: ~/c++/libcw_branch-threading/src/libcwd/tests>vi hello_world.ii ~/c++/libcw_branch-threading/src/libcwd/tests>/usr/local/gcc-3.0.1/lib/gcc-lib/i686-pc-linux-gnu/3.0.1/cc1plus -fpreprocessed hello_world.ii -quiet -dumpbase hello_world.cc -g -version -o hello_world.s GNU CPP version 3.0.1 (cpplib) (i386 Linux/ELF) GNU C++ version 3.0.1 (i686-pc-linux-gnu) compiled by GNU C version 3.0.1. In file included from /usr/local/gcc-3.0.1/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98, from /usr/local/gcc-3.0.1/include/g++-v3/i686-pc-linux-gnu/bits/c++io.h:37, from /usr/local/gcc-3.0.1/include/g++-v3/bits/fpos.h:39, from /usr/local/gcc-3.0.1/include/g++-v3/bits/std_iosfwd.h:41, from /usr/local/gcc-3.0.1/include/g++-v3/bits/std_ios.h:39, from /usr/local/gcc-3.0.1/include/g++-v3/bits/std_ostream.h:39, from /usr/local/gcc-3.0.1/include/g++-v3/bits/std_iostream.h:40, from /usr/local/gcc-3.0.1/include/g++-v3/iostream:31, from ../include/libcw/debug.h:81, from hello_world_debug.h:18, from hello_world.cc:28: /usr/local/gcc-3.0.1/include/g++-v3/i686-pc-linux-gnu/bits/gthr-default.h:48:2: invalid preprocessing directive #xxxpragma Apparently, the pragma's are in bits/gthr-default.h:48. Hmm, maybe I can reproduce this after all by including #include <iosfwd> in the small test case... ~>g++-3.0.1 test.cc -o test ~>./test Segmentation fault (core dumped) Yup, that does the trick. I think this is highly annoying. The #pragma weak should not make the linker think the function exists :/. Release: 3.0.1 Environment: i686-rawhide-gnu-linux How-To-Repeat: Compile the following code snippet and don't link with -lpthread (no error occurs): #include <iosfwd> #include <pthread.h> static pthread_once_t S_key_once; static pthread_key_t S_key; void S_destroy(void* tsd_ptr) throw() { } void S_alloc_key(void) throw() { pthread_key_create(&S_key, S_destroy); } int main(void) { pthread_once(&S_key_once, S_alloc_key); } Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/0 ------------------------------------------------------------------------ On 2001-09-20T17:26:00+00:00 Carlo Wood wrote: Fix: Link with -lpthread Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/1 ------------------------------------------------------------------------ On 2002-03-11T13:46:00+00:00 Pme-n wrote: State-Changed-From-To: open->feedback State-Changed-Why: Carlo, Is this problem still occuring? I've changed the category because libstdc++ has no control over platform threads, nor over what happens (or doesn't happen) when #pragma's are seen. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/2 ------------------------------------------------------------------------ On 2003-01-14T15:10:22+00:00 Bangerth wrote: State-Changed-From-To: feedback->closed State-Changed-Why: No feedback (at least not in audit trail) Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/3 ------------------------------------------------------------------------ On 2003-01-15T01:23:32+00:00 Carlo Wood wrote: From: Carlo Wood <[email protected]> To: [email protected], [email protected], [email protected], [email protected], [email protected] Cc: Subject: Re: c/4372: #pragma weak pthread* inclusion causes applications to crash without a linker error when one forgets to link with -lpthread Date: Wed, 15 Jan 2003 01:23:32 +0100 On Tue, Jan 14, 2003 at 11:10:22PM -0000, [email protected] wrote: > Synopsis: #pragma weak pthread* inclusion causes applications to crash > without a linker error when one forgets to link with -lpthread > > State-Changed-From-To: feedback->closed > State-Changed-By: bangerth > State-Changed-When: Tue Jan 14 15:10:22 2003 > State-Changed-Why: > No feedback (at least not in audit trail) > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4372 Well, open it again because yes - this problem still exists with 3.2.1. >g++ test.cc -o test >./test Segmentation fault and >g++ test.cc -o test -lpthread >./test > I don't understand why you needed to feedback though. The small test case is simple enough, no? Still, >cat test.cc #include <iosfwd> #include <pthread.h> static pthread_once_t S_key_once; static pthread_key_t S_key; void S_destroy(void* tsd_ptr) throw() { } void S_alloc_key(void) throw() { pthread_key_create(&S_key, S_destroy); } int main(void) { pthread_once(&S_key_once, S_alloc_key); } -- Carlo Wood <[email protected]> Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/4 ------------------------------------------------------------------------ On 2003-01-15T06:29:01+00:00 Ehrhardt-j wrote: State-Changed-From-To: closed->analyzed State-Changed-Why: This testcase boils down to the following: extern void f (); #pragma weak f int main(void) { f(); } This compiles and links fine despite the missing symbol for f. This is correct (documented) behaviour as analyzed below. BUT: This construct (external declaration combined with weak pragma) is used in header files provided by gcc (gthr-default.h). The effect is that programs that use this header file can be linked without error messages even if they aren't linked against libpthread. Hoever these programs crash when executed. Is there really any need for these pragmas at all? As far as I can see the situation is this: With pragmas: * If the functions aren't used everything works fine. * If the functions are used but there is no implementation for them the program compiles and links but crashes at run time. Without pragmas: * If the functions aren't used everything works fine. If the functions are used but there is no implementation for them the program compiles (to a .o) but it doesn't link. I'd highly prefer the latter, i.e. we get an error message instead of a broken executable. If the intention is to make the implementation of these functions weak, why can't this be done in the corresponding .c file that implements the function? Here are the exceprts form the manual to prove that the current behaviour of gcc is as documented: From gccs info file: | `weak' | The `weak' attribute causes the declaration to be emitted as a weak | symbol rather than a global. This is primarily useful in defining | library functions which can be overridden in user code, though it | can also be used with non-function declarations. Weak symbols are | supported for ELF targets, and also for a.out targets when using | the GNU assembler and linker. Note that this explicitly mentions declarations, not just definitions. The nm manual page describes the behaviour of weak symbols as follows: | "W" The symbol is a weak symbol that has not been | specifically tagged as a weak object symbol. When a | weak defined symbol is linked with a normal defined | symbol, the normal defined symbol is used with no | error. When a weak undefined symbol is linked and | the symbol is not defined, the value of the weak | symbol becomes zero with no error. The last sentence applies to our situation: A weak undefined symbol is replaced with zero and no error occurs. regards Christian Ehrhardt Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/5 ------------------------------------------------------------------------ On 2003-08-04T01:14:05+00:00 Pinskia wrote: This only happens when pthread_* is not in libc and targets where weak is supported. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/6 ------------------------------------------------------------------------ On 2003-08-04T04:07:08+00:00 Pme-n wrote: Not just "not in libc" but "not in any of the standard libraries against which a program is linked". Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/7 ------------------------------------------------------------------------ On 2003-11-07T14:57:50+00:00 Carlo-2 wrote: Still in mainline. Can't we just remove the #pragma's from bits/gthr-default.h? That was the suggestion solution in this thread and it makes sense to me. If not, then please just close this PR with a WONTFIX. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/8 ------------------------------------------------------------------------ On 2005-11-09T20:13:50+00:00 Aoliva-a wrote: Subject: Bug 4372 Author: aoliva Date: Wed Nov 9 20:13:41 2005 New Revision: 106703 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106703 Log: PR other/4372 * tree.h (IDENTIFIER_TRANSPARENT_ALIAS): New. (TREE_DEPRECATED): Adjust comment. Check for a DECL. * c-common.c (handle_weakref_attribute): New. (c_common_attribute_table): Add weakref. * configure.ac (HAVE_GAS_WEAKREF): Check for weakref support in the assembler. * configure, config.in: Rebuilt. * defaults.h (ASM_OUTPUT_WEAKREF): Define if HAVE_GAS_WEAKREF. * doc/extend.texi: Document weakref attribute. * varasm.c (ultimate_transparent_alias_target): New (assemble_name): Use it. (weak_finish_1): Split out of... (weak_finish): ... and deal with weakrefs in... (weakref_targets): ... new list. (globalize_decl): Clean up weakref_targets. (do_assemble_alias): Handle weakrefs. (finish_aliases_1): Do not reject weakrefs to external symbols. (assemble_alias): Handle weakrefs. Added: trunk/gcc/testsuite/gcc.dg/attr-weakref-1.c trunk/gcc/testsuite/gcc.dg/attr-weakref-1a.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/defaults.h trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C trunk/gcc/tree.h trunk/gcc/varasm.c Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/9 ------------------------------------------------------------------------ On 2005-11-09T20:57:35+00:00 Aoliva-a wrote: Subject: Bug 4372 Author: aoliva Date: Wed Nov 9 20:57:30 2005 New Revision: 106704 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106704 Log: gcc/ChangeLog: PR other/4372 * gthr-dce.h, gthr-posix.h, gthr-posix95.h, gthr-solaris.h, gthr-tpf.h: Define __gthrw. For all identifiers that might be weak, introduce weakrefs or non-weak aliases with __gthrw, and prefix all uses with __ghtrw. libobjc/ChangeLog: PR other/4372 * thr-objc.c (_XOPEN_SOURCE): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/gthr-dce.h trunk/gcc/gthr-posix.h trunk/gcc/gthr-posix95.h trunk/gcc/gthr-solaris.h trunk/gcc/gthr-tpf.h trunk/libobjc/ChangeLog trunk/libobjc/thr-objc.c Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/10 ------------------------------------------------------------------------ On 2005-11-09T20:58:51+00:00 Aoliva-a wrote: Fixed Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/11 ------------------------------------------------------------------------ On 2005-11-10T13:14:09+00:00 Jakub-gcc wrote: Subject: Bug 4372 Author: jakub Date: Thu Nov 10 13:14:05 2005 New Revision: 106735 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106735 Log: PR other/4372 * varasm.c (assemble_alias): Use %q+D in the error message instead of %J and %qD. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/12 ------------------------------------------------------------------------ On 2005-12-09T04:56:55+00:00 Pinskia wrote: *** Bug 14952 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/18 ------------------------------------------------------------------------ On 2006-10-04T21:39:19+00:00 Pinskia wrote: *** Bug 29350 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.0/+bug/26663/comments/21 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/26663 Title: gthr.h: _GLIBCXX_GTHREAD_USE_WEAK is 1 by default ? To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/26663/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
