From patchwork Mon Mar 14 18:40:38 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos O'Donell X-Patchwork-Id: 597226 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3qP65W24Vtz9sdt for ; Tue, 15 Mar 2016 05:41:03 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=cR9Nx3iJ; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:cc:message-id:date:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=GombsAqRuv/Sv1jv Ttf8hF2Fd2avAjnzOCiarzI76gBwLvGvD6BHmDPQ44VUgOXD8Yg7P9GlnMVz1FrX CK2mx2ZADx6iMzHRKcnwgHIHMc0hfjxJgeyufU3AtX0pHhPQ4T1HVRoRFyTOPzcJ d9l6WBxiFJnaPVKIBN17n4kJbTc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:cc:message-id:date:mime-version:content-type :content-transfer-encoding; s=default; bh=O2Blae/x8WFFAwwfLrhf8G 3vZzk=; b=cR9Nx3iJ3XxwrrsUlfZL6ugQSqgEqkmjHbRJcdYMVAlxHGVzXUx/BI PYEXEjPC4Y8ANSofUnWmmD4MXhznCO6xu4lDiHXfhJpIb03UdP0UIJzrdv+q1NhC 7BbKTKVh5KLWYlGywrR6j4ALyLvqTFsW9MSwjtnfEdx8Y/eo3+N6A= Received: (qmail 78328 invoked by alias); 14 Mar 2016 18:40:46 -0000 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 Received: (qmail 77755 invoked by uid 89); 14 Mar 2016 18:40:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=rightly, clarifications, lastly, Expand X-HELO: mail-qk0-f169.google.com Received: from mail-qk0-f169.google.com (HELO mail-qk0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 14 Mar 2016 18:40:44 +0000 Received: by mail-qk0-f169.google.com with SMTP id s68so78764354qkh.3 for ; Mon, 14 Mar 2016 11:40:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:cc:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=ouJlBU7gIoTkk6qjQNIboWg/sO9JW3yE3hByDjX0Y/4=; b=aKQKZdjO72/Uz7Rlcy0heAEVMReeQLqspkq2KyODVvM/Q17llrf0Xv05Lcf9F0QrJf /CV8eJVraGbBUlvJVvNjbo6YKu22Njkd/uVZaLIBlT3UNijttis6UxjOIdaLEFvYUD+O cf4cc7KeKp8Pr6sEmx9RR0+48/nYW4BPw/cY41e34z2uyYlZRi28zHuMmt4nS8JQ3dht 6TMBnJ61u5h0JVR0vgCNdStSO3hsOW9d9WnewZ+YL6zpW9+vEp3FQxyZuzpcbMlGrIPv wSuA16wob8OL4ESK+MOMtQnRS0+0vrfsUe38K759Go+7geK6tqVZEdBAZPw638xt6hUN SQhw== X-Gm-Message-State: AD7BkJJnxOWsVIyUkNsNmpe5rNnElJY1p+A69x5/uWtcyaH3xr6yeEwjWDdcmVZsrwYqFc5D X-Received: by 10.55.81.3 with SMTP id f3mr32511515qkb.35.1457980841911; Mon, 14 Mar 2016 11:40:41 -0700 (PDT) Received: from [192.168.2.15] (bas1-pembroke52-1279338163.dsl.bell.ca. [76.65.38.179]) by smtp.gmail.com with ESMTPSA id s75sm10888901qge.17.2016.03.14.11.40.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2016 11:40:41 -0700 (PDT) To: gcc-patches@gcc.gnu.org From: Carlos O'Donell Subject: [PATCH] extend.texi: Expand on the perils of using the 'leaf' attribute. Cc: "Joseph S. Myers" , Florian Weimer Message-ID: <56E705A6.5040108@redhat.com> Date: Mon, 14 Mar 2016 14:40:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Using the 'leaf' attribute is difficult in certain use cases, and the documentation rightly points out that signals is one such problem. We should additionally document the following caveats: * Indirect function resolvers (thanks to Florian Weimer for catching this). * Indirect function implementations * ELF symbol interposition. Note that neither the C nor C++ standards talks at all about how memory is synchronized between the current execution context and that of a signal handler. Therefore this patch rewords the text to say "There is no standards compliant way..." although in practice is just works and one would expect the standards (POSIX) to adopt such language that existing practice works. Lastly, we mention that the 'leaf' attribute might simply be removed if that is the easiest option. OK to checkin? For completeness the motivating example from a user was like this: cat >> leaf.c < #include #include #include static int tst; void my_h(int sig) { if (tst == 1) _exit (0); _exit (1); } int main() { signal(SIGUSR1, my_h); tst++; pthread_kill(pthread_self(), SIGUSR1); tst--; return 2; } EOF gcc -g3 -O3 -o leaf leaf.c -lpthread ./test; echo $? 1 Where the global write of tst is elided by the compiler because pthread_kill is marked __THROW (includes leaf). It's an open question if pthread_kill should or should not use __THROWNL. Even if we fix that in glibc, the changes below to the docs are still important clarifications. gcc/ 2016-03-14 Carlos O'Donell * doc/extend.texi (Common Function Attributes): Describe ifunc impact on leaf attribute. --- Cheers, Carlos. Index: extend.texi =================================================================== --- extend.texi (revision 234183) +++ extend.texi (working copy) @@ -2786,9 +2786,17 @@ is a leaf function, but @code{qsort} is not. Note that leaf functions might invoke signals and signal handlers might be -defined in the current compilation unit and use static variables. The only -compliant way to write such a signal handler is to declare such variables -@code{volatile}. +defined in the current compilation unit and use static variables. Similarly, +when lazy symbol resolution is in effect, leaf functions might invoke indirect +functions whose resolver function or implementation function might be defined +in the current compilation unit and use static variables. There is no standards +compliant way to write such a signal handler, resolver function, or +implementation function, and the best that you can do is to remove the leaf +attribute or mark all such variables @code{volatile}. Lastly, for ELF-based +systems which support symbol interposition one should take care that functions +defined in the current compilation unit do not unexpectedly interpose other +symbols based on the defined standards mode otherwise an inadvertent callback +would be added. The attribute has no effect on functions defined within the current compilation unit. This is to allow easy merging of multiple compilation units into one,