[Bug c/14952] New: libgcc_eh.a broken with respect to pthreads & static linking

[Bug c/14952] New: libgcc_eh.a broken with respect to pthreads & static linking

[rassahah at neofonie dot de]

same as #4372?
libgcc_eh contains a file unwind-dw2-fde-glibc.o that seems to be linked with an executable when
a program is compiled with -static. In that is the function __register_frame_info_bases, which makes
a very suspicious use of weak symbols to change its behaviour depending on the usage of threads
in the program. The program below crashes in __register_frame_info_bases(), because some of
the weak symbols are not defined while others are. It seems that __register_frame_info_bases relies
on the assumption, that if one pthread_* function is defined another will also be defined, which is not
the case depending on the libc-version (works with glibc/linuxthreads, not with glibc/nptl). Note
that this bug is strongly related to #4372, i entered a new one since this is addressing inconsistencies
within gcc itself (represented by libgcc_eh) and #4372 addresses the affection of gcc-headers to the
application program. Additionally i see no workaround except giving lots of -u options to the linker
or use some other way to pull in all used pthread_* functions by hand. Simply removing the
`#pragma weak' declarations from the headers does not work cause then one has to include the
pthread_* functions always. At least not as far as i tried.

Greetings - Rasmus

System information: gcc-3.3.3, binutils-2.14.90, glibc-2.3.3/nptl

int zero = 0;
int main () { /* compile with -static -lpthread */
    if (zero) { /* dont optimize away */
       pthread_key_create (0, 0); /* not called, but linked */
    }
}

-- 
           Summary: libgcc_eh.a broken with respect to pthreads & static
                    linking
           Product: gcc
           Version: 3.3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rassahah at neofonie dot de
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14952

[Bug other/14952] libgcc_eh.a broken with respect to pthreads & static linking

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-14 11:56 -------
Yes it checks for pthread_create and only pthread_create byt I think this is the correct behaviour for 
GCC to do, how about writting a bug against glibc and seeing what they say.  Also it has nothing to 
with bug 4372 really because in that bug the header is pulled in through libstdc++ headers.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c                           |other
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-04-14 11:56:26
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14952

[Bug other/14952] libgcc_eh.a broken with respect to pthreads & static linking

[rassahah at neofonie dot de]

------- Additional Comments From rassahah at neofonie dot de  2004-04-14 12:53 -------
Yes, thats the problem as far as i can see. In __register_frame_info_bases a call to
__gthread_mutex_lock is made. This turns to be out to check for presence pthread_create
(via a call to __gthread_active_p) and then calls pthread_mutex_lock () which might or might not
be defined (not defined in my case). pthread_create seems to be defined only by accident, since its 
object file defines some symbol that is needed by pthread_key_create (). I do not know if this
behaviour is correct but the heuristic used in gcc (if pthread_create exists => call pthread_mutex_lock)
is at least a bit dangerous. Better would be something like:
if pthread_create exists => force linking of pthread_mutex_lock and call it.
As this cannot be achieved simply with only `#pragma weak's some more symbol-linking-mess is
probably required here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14952

[Bug other/14952] libgcc_eh.a broken with respect to pthreads & static linking

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-14 00:21 -------
Really exceptions are not supported with static linking, just like some parts of glibc are not supported 
with static linking any more.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14952

[Bug other/14952] libgcc_eh.a broken with respect to pthreads & static linking

[eric dot valette at free dot fr]

------- Additional Comments From eric dot valette at free dot fr  2004-11-09 09:30 -------
I can confirm this bug with glibc cvs (yesterday) and gcc-3.4.2. The result is
that it is not possible to run the Open Posix test suite with glibc compiled as
NPTL + static library.

I have a real world RT application on linux where dynamic linking lead to a
VmSize of 70 Mb whereas static linling leads to VmSize = 10 Mb. The problem is
that you need to do mlockall to avoid page faults...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eric dot valette at free dot
                   |                            |fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14952

[Bug other/14952] libgcc_eh.a broken with respect to pthreads & static linking

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2005-12-09 04:56 -------
(In reply to comment #4)
> I have a real world RT application on linux where dynamic linking lead to a
> VmSize of 70 Mb whereas static linling leads to VmSize = 10 Mb. The problem > is that you need to do mlockall to avoid page faults...

VMSize means nothing as most of the code is just mapped in and nothing else.
And if the VM shit, then really it is not a GCC bug.

Anyways this is really a dup of bug 4372.

*** This bug has been marked as a duplicate of 4372 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14952