From patchwork Fri Jan 27 01:07:38 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roland McGrath X-Patchwork-Id: 138095 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 503A7B6F13 for ; Fri, 27 Jan 2012 12:08:02 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1328231282; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:Message-Id:From:To:Subject:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=gP0H5fjwAViJQFUT5dDSdOnJdME=; b=sYxrH/F6agSV8wIi3wScjMZo0XCuQxmLYHSQ2aShBwNWKSfjI0KfFreheAkPHV /RUE4UumVgLw5dWgJhZXk/sbe2s/1l4JfYIITs8jUB0oE7z2KWHNECMS/EuNuI7/ RdhemqWU/xGFR/F1kBuqZ9Fwl0RCympNjuWCHRyLva9gk= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:Message-Id:From:To:Subject:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=YlfV8TDD2a/21H88sHLSV5V72H8yb8Lcf0jqNN5OwpBnSESGg4MEEt7JMP+KOy Ab+5gQ2GeAvkx+MlhdF6ylZA3GInI2EeU5ym7vABNPxzW7grrIdMQSOTTNrbuX4n vVQ8nsDDUPyC9HbJNC+IrYY32Kv7CGHxGiW450cj85xio=; Received: (qmail 25019 invoked by alias); 27 Jan 2012 01:07:57 -0000 Received: (qmail 25008 invoked by uid 22791); 27 Jan 2012 01:07:55 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-iy0-f175.google.com (HELO mail-iy0-f175.google.com) (209.85.210.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Jan 2012 01:07:42 +0000 Received: by iaby12 with SMTP id y12so546325iab.20 for ; Thu, 26 Jan 2012 17:07:42 -0800 (PST) Received: by 10.50.153.198 with SMTP id vi6mr4402287igb.30.1327626462004; Thu, 26 Jan 2012 17:07:42 -0800 (PST) Received: by 10.50.153.198 with SMTP id vi6mr4402277igb.30.1327626461899; Thu, 26 Jan 2012 17:07:41 -0800 (PST) Received: from frobland.mtv.corp.google.com.google.com ([2620:0:1000:1b01:6631:50ff:fe3b:961a]) by mx.google.com with ESMTPS id bj1sm2693252igb.0.2012.01.26.17.07.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 17:07:41 -0800 (PST) Date: Thu, 26 Jan 2012 17:07:38 -0800 Message-Id: From: Roland McGrath To: gcc-patches@gcc.gnu.org Subject: [PATCH] libgcc: refer to pthread_create, not pthread_cancel Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org For GNU systems, the fact that libgcc/libstdc++ refers to pthread_cancel is utterly bizarre. I don't know of any rationale for this that has ever applied to glibc. AFAICT the choice was made based on the foibles of various non-glibc systems. In practice, things are working fine on GNU systems now, of course. But they'd work just as well for all extant glibc versions if the reference were to pthread_create instead. That's what makes clear sense on its face: if the program is multithreaded, pthread_create is the one function that certainly must have been linked in. It is actively troublesome for the case of static linking. It necessitates linking in a lot of dead code in a program that uses pthreads but doesn't use pthread_cancel. It only actually works right at all because glibc added a special hack to cope with this bizarre reference to pthread_cancel. It would be nice if we could remove that someday. (I don't intend to start any general discussion here about the level of support for static linking. It's just an example of what's nonsensical about this usage.) With any kind of linking, it has whatever side effects linking in pthread_cancel has. There is at least one port of glibc (to a non-GNU system) where pthread_cancel has a link-time warning because it's not fully supported. Getting this warning on every link that uses C++ at all is rather bewildering, especially to application developers who don't use pthreads directly at all or don't have any idea what pthread_cancel is. What do folks think about this change? It obviously should have no effect whatsoever on builds not using glibc. I'm pretty confident that it won't have any bad effect on a build using any extant version of glibc that had pthreads at all. Thanks, Roland 2012-01-26 Roland McGrath * gthr-posix.h [neither FreeBSD nor Solaris] (__gthread_active_p): If __GLIBC__ is defined, refer to pthread_create, not pthread_cancel. diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h index 46054f6..688253d 100644 --- a/libgcc/gthr-posix.h +++ b/libgcc/gthr-posix.h @@ -241,18 +241,24 @@ __gthread_active_p (void) #else /* neither FreeBSD nor Solaris */ +/* The bionic (Android) C library does not provide pthread_cancel. + The GNU C library provides pthread_cancel, but it is a poor + choice there. For static linking, referring to pthread_cancel + causes it to be linked in even when it's never actually used. + For a program to be multi-threaded the only thing that it + certainly must be using is pthread_create. */ + +#if defined(__GLIBC__) || defined(__BIONIC__) +# define GTHR_ACTIVE_PROXY __gthrw_(pthread_create) +#else +# define GTHR_ACTIVE_PROXY __gthrw_(pthread_cancel) +#endif + static inline int __gthread_active_p (void) { -/* Android's C library does not provide pthread_cancel, check for - `pthread_create' instead. */ -#ifndef __BIONIC__ static void *const __gthread_active_ptr - = __extension__ (void *) &__gthrw_(pthread_cancel); -#else - static void *const __gthread_active_ptr - = __extension__ (void *) &__gthrw_(pthread_create); -#endif + = __extension__ (void *) >HR_ACTIVE_PROXY; return __gthread_active_ptr != 0; }