From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46185 invoked by alias); 27 Mar 2015 09:30:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 46080 invoked by uid 89); 27 Mar 2015 09:30:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp10.uk.ibm.com Received: from e06smtp10.uk.ibm.com (HELO e06smtp10.uk.ibm.com) (195.75.94.106) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 27 Mar 2015 09:30:47 +0000 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 27 Mar 2015 09:30:43 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 27 Mar 2015 09:30:40 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 7FD1E219005F for ; Fri, 27 Mar 2015 09:30:28 +0000 (GMT) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2R9UeuQ7012842 for ; Fri, 27 Mar 2015 09:30:40 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2R9UdB7018337 for ; Fri, 27 Mar 2015 03:30:39 -0600 Received: from [9.152.212.204] (dyn-9-152-212-204.boeblingen.de.ibm.com [9.152.212.204]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t2R9UdAS018311; Fri, 27 Mar 2015 03:30:39 -0600 Message-ID: <5515233E.2010406@linux.vnet.ibm.com> Date: Fri, 27 Mar 2015 09:30:00 -0000 From: Andreas Krebbel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jakub Jelinek CC: gcc-patches@gcc.gnu.org, vogt@linux.vnet.ibm.com Subject: Re: [PATCH] S390: Hotpatching fixes. References: <20150305124019.GA6266@linux.vnet.ibm.com> <20150309112221.GA4801@linux.vnet.ibm.com> <20150309121938.GA11867@linux.vnet.ibm.com> <20150326205630.GH1746@tucnak.redhat.com> In-Reply-To: <20150326205630.GH1746@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15032709-0041-0000-0000-000003BB00F4 X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg01417.txt.bz2 On 03/26/2015 09:56 PM, Jakub Jelinek wrote: > Hi! > > On Mon, Mar 09, 2015 at 01:19:38PM +0100, Dominik Vogt wrote: >> @@ -11368,6 +11349,7 @@ static void >> s390_reorg (void) >> { >> bool pool_overflow = false; >> + int hw_before, hw_after; >> >> /* Make sure all splits have been performed; splits after >> machine_dependent_reorg might confuse insn length counts. */ >> @@ -11503,6 +11485,40 @@ s390_reorg (void) >> if (insn_added_p) >> shorten_branches (get_insns ()); >> } >> + >> + s390_function_num_hotpatch_hw (current_function_decl, &hw_before, &hw_after); >> + if (hw_after > 0) > > Two minor issues, both for nested functions: > > 1) the s390_function_num_hotpatch_hw assigns to ints whose addresses are > passed as arguments, even when it later decides to return false and in this > spot you ignore the return value. Which means that hw_after could be > non-zero, even when you should be ignoring it. > So, either you should check above the return value too, or > change s390_function_num_hotpatch_hw so that it stores 0 for the nested > functions before returning false. > 2) as s390_function_num_hotpatch_hw is now called twice for the same > function, for nested functions you'll get the warning reported twice too. > Perhaps add some additional argument whether you want the warning or not > and use it in one of the callers and not in the other one? > Plus supposedly add testsuite coverage for that. At a second glance it is not really clear to me why we disable hotpatching for nested functions at all. While it is probably a bit difficult to actually hotpatch them I don't see why we should prevent it. We probably just copied that over from the x86 ms_hook_prologue attribute implementation: static bool ix86_function_ms_hook_prologue (const_tree fn) { if (fn && lookup_attribute ("ms_hook_prologue", DECL_ATTRIBUTES (fn))) { if (decl_function_context (fn) != NULL_TREE) error_at (DECL_SOURCE_LOCATION (fn), "ms_hook_prologue is not compatible with nested function"); else return true; } return false; } Also the kernel guys (one of the main users of that feature) confirmed that they in principle prefer hotpatching to behave more like -pg and -pg does insert an mcount call for nested functions. (Although I would be surprised to hear of nested functions in the Linux kernel). So I'm inclined to just remove that special handling of nested functions. This would also fix 1) Bye, -Andreas-