From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 354C8C282CE for ; Tue, 4 Jun 2019 13:25:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0D01C24291 for ; Tue, 4 Jun 2019 13:25:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=agner.ch header.i=@agner.ch header.b="HG5nfXC5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727392AbfFDNZA (ORCPT ); Tue, 4 Jun 2019 09:25:00 -0400 Received: from mail.kmu-office.ch ([178.209.48.109]:48336 "EHLO mail.kmu-office.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727340AbfFDNZA (ORCPT ); Tue, 4 Jun 2019 09:25:00 -0400 Received: from trochilidae.toradex.int (unknown [46.140.72.82]) by mail.kmu-office.ch (Postfix) with ESMTPSA id 8BE845C2138; Tue, 4 Jun 2019 15:24:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agner.ch; s=dkim; t=1559654695; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=2lQNwDLO9/HfsHTvSmLn5csGG1S09yt0LuSYqXeE0y0=; b=HG5nfXC5qPZvu4E7tM2iveXY8wtjralMObB8KMvD1S6NWkkOwkeLjXonm495Hz+G+geOig NlbMrAg5b6wYCzvMgqUeSBmGkYCjB/7IFlotEiTcUNmOCorD2pTasqUOcpObuc6WqBkEjM 3seyrLJVs51y9A3weXf9CMO3OMOXwRA= From: Stefan Agner To: gregkh@linuxfoundation.org Cc: stable@vger.kernel.org, Miguel Ojeda , Martin Sebor , Nick Desaulniers , Stefan Agner Subject: [PATCH BACKPORT 4.19 1/2] Compiler Attributes: add support for __copy (gcc >= 9) Date: Tue, 4 Jun 2019 15:24:40 +0200 Message-Id: <20190604132441.15383-1-stefan@agner.ch> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Archived-At: List-Archive: List-Post: From: Miguel Ojeda [ Upstream commit c0d9782f5b6d7157635ae2fd782a4b27d55a6013 ] >From the GCC manual: copy copy(function) The copy attribute applies the set of attributes with which function has been declared to the declaration of the function to which the attribute is applied. The attribute is designed for libraries that define aliases or function resolvers that are expected to specify the same set of attributes as their targets. The copy attribute can be used with functions, variables, or types. However, the kind of symbol to which the attribute is applied (either function or variable) must match the kind of symbol to which the argument refers. The copy attribute copies only syntactic and semantic attributes but not attributes that affect a symbol’s linkage or visibility such as alias, visibility, or weak. The deprecated attribute is also not copied. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html The upcoming GCC 9 release extends the -Wmissing-attributes warnings (enabled by -Wall) to C and aliases: it warns when particular function attributes are missing in the aliases but not in their target, e.g.: void __cold f(void) {} void __alias("f") g(void); diagnoses: warning: 'g' specifies less restrictive attribute than its target 'f': 'cold' [-Wmissing-attributes] Using __copy(f) we can copy the __cold attribute from f to g: void __cold f(void) {} void __copy(f) __alias("f") g(void); This attribute is most useful to deal with situations where an alias is declared but we don't know the exact attributes the target has. For instance, in the kernel, the widely used module_init/exit macros define the init/cleanup_module aliases, but those cannot be marked always as __init/__exit since some modules do not have their functions marked as such. Cc: # 4.14+ Suggested-by: Martin Sebor Reviewed-by: Nick Desaulniers Signed-off-by: Miguel Ojeda Signed-off-by: Stefan Agner --- include/linux/compiler-gcc.h | 4 ++++ include/linux/compiler_types.h | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h index a8ff0ca0c321..3ebee1ce6f98 100644 --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -345,6 +345,10 @@ #endif /* gcc version >= 40000 specific checks */ +#if GCC_VERSION >= 90100 +#define __copy(symbol) __attribute__((__copy__(symbol))) +#endif + #if !defined(__noclone) #define __noclone /* not needed */ #endif diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h index c2ded31a4cec..2b8ed70c4c77 100644 --- a/include/linux/compiler_types.h +++ b/include/linux/compiler_types.h @@ -261,6 +261,10 @@ struct ftrace_likely_data { #define __visible #endif +#ifndef __copy +# define __copy(symbol) +#endif + #ifndef __nostackprotector # define __nostackprotector #endif -- 2.21.0