Message ID | 20221028143346.183569-3-sv@linux.ibm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp870061wru; Fri, 28 Oct 2022 07:42:33 -0700 (PDT) X-Google-Smtp-Source: AMsMyM695uqGGGRc4INkCOJAkFctAnrCqLBXqdKEDSXsSk9gI1XiHMj+0jQ5Ac4rYlmJgEv5YCeb X-Received: by 2002:a17:90b:4f4d:b0:20d:2225:4275 with SMTP id pj13-20020a17090b4f4d00b0020d22254275mr17102399pjb.191.1666968153412; Fri, 28 Oct 2022 07:42:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666968153; cv=none; d=google.com; s=arc-20160816; b=wnHicY3y6vPfM9b/aRMnGcTSx8C1OPJwSSBoRqkS4PV1xHvrEBGkVrl90VgcqW2BwY dTy5a1F7U3EoHRJASH5Bfzme8tHAC0TLFN89E4x4EXSe9gdGVuIZ8MjCqhN1fvAlZGVU tG3j6owCqkJOSiLVGw/5jfYWrIFmSWNpsCdI5rPfTxQms07/gcvCM+pVO46x9Ixp7Xva b42avKjlc+U3ve9663NIWG9G+rL1aEpTBeEs+4vrbQGcxUNjrrqHrqXi0Ks2QyrERuzh xiQOCtGDO9Htsofm2vL3MmbI8mWqS/dNi8rN6ujbox81uldYWgGPwSImq+89o4gIPCqh PyQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=7jYbvwrO75UF/CO+Wo9zTpxfnd+02JX5CHnpOUD1pLE=; b=xBa7lbn9mCJZ7ys7+aSCJChQea11VCghnwhp3nL8RzOtG42tFyEtYQkDHZO9iCJ8Q9 Gv2+++hk8Gk8t9g0UF70LeFlEzvtcXBeJV72ta7Vh50DHHNhIicrr9iJQBNv/1HhuVaS DXsZaQqVmC4HE34Uev8RZtsHP79f0m+rwaa9rI+Bpttyy08r08nSl3HxjwhS3+441d/q ElqV0xcXXQn5D+YDnoR5dZyOOK1kzAoZYNCAgfwm6+zG7/qu2V+pyMHaursxo2kE259e 6NBcw1ivVHvV0aRvOL9JKbaarlzBwDgP/ZbvaJVTRWi+dJYHDHstfcv2eK7hHtvUwjKA wk/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b="g/+MXk8w"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f17-20020a63f111000000b0045ec918ad38si4963992pgi.548.2022.10.28.07.42.19; Fri, 28 Oct 2022 07:42:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b="g/+MXk8w"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230408AbiJ1Oew (ORCPT <rfc822;chrisfriedt@gmail.com> + 99 others); Fri, 28 Oct 2022 10:34:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230391AbiJ1Oer (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 28 Oct 2022 10:34:47 -0400 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05EB313F0D for <linux-kernel@vger.kernel.org>; Fri, 28 Oct 2022 07:34:40 -0700 (PDT) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29SEB7Os026447; Fri, 28 Oct 2022 14:34:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding; s=pp1; bh=7jYbvwrO75UF/CO+Wo9zTpxfnd+02JX5CHnpOUD1pLE=; b=g/+MXk8whueK4/alEmKT8Tmd9JUfHMkGpI4d5tnYobC0kYbKDhUB6MglbDhaP8zZC8Bj sQdN9QQaiWzxei+T5yk44YM0hoV8Ruw3dMRvgN2ro5JvSeZD7C5RSqjIRSiWqe2TK7py 3x+OScXofStZMiqE2qCZhNVyDcj/2gu67lXTyyBj+XsPL+CmxKMP3XiudSdErBC8ICxK hAdTZyw5DZkb06tnsbAsMjvPE1j/y7uq/XxnTTiuf9ayJrz4LLvcIvbQpsCUy7FR5gdY BunwKEQlScBrbrvgKZ4OOpHvSRYkwMpP+V94VDEIeHz6WmLw4GcTRxqRn+4KKy2HtF2S hw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3kggm70w88-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Oct 2022 14:34:22 +0000 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 29SECHFq032543; Fri, 28 Oct 2022 14:34:21 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3kggm70w5x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Oct 2022 14:34:21 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 29SELBUJ026505; Fri, 28 Oct 2022 14:34:18 GMT Received: from b06avi18878370.portsmouth.uk.ibm.com (b06avi18878370.portsmouth.uk.ibm.com [9.149.26.194]) by ppma06ams.nl.ibm.com with ESMTP id 3kfahu3wwr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Oct 2022 14:34:18 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06avi18878370.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 29SEYpRu51052978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 28 Oct 2022 14:34:51 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5931EA404D; Fri, 28 Oct 2022 14:34:16 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6B1EBA4040; Fri, 28 Oct 2022 14:34:12 +0000 (GMT) Received: from li-c3569c4c-1ef8-11b2-a85c-ee139cda3133.ibm.com.com (unknown [9.43.124.163]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 28 Oct 2022 14:34:12 +0000 (GMT) From: Sathvika Vasireddy <sv@linux.ibm.com> To: linuxppc-dev@lists.ozlabs.org Cc: jpoimboe@redhat.com, peterz@infradead.org, linux-kernel@vger.kernel.org, aik@ozlabs.ru, mpe@ellerman.id.au, mingo@redhat.com, christophe.leroy@csgroup.eu, rostedt@goodmis.org, mbenes@suse.cz, npiggin@gmail.com, chenzhongjin@huawei.com, naveen.n.rao@linux.vnet.ibm.com, sv@linux.ibm.com Subject: [PATCH v5 02/16] powerpc: Override __ALIGN and __ALIGN_STR macros Date: Fri, 28 Oct 2022 20:03:32 +0530 Message-Id: <20221028143346.183569-3-sv@linux.ibm.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20221028143346.183569-1-sv@linux.ibm.com> References: <20221028143346.183569-1-sv@linux.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: lUkNUzuI_ALeZ-Ylvb6yf45mCzqZbmmy X-Proofpoint-GUID: f37CHked2wq6wk8aqujtttErY_-7tP_Q X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-10-28_07,2022-10-27_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=948 impostorscore=0 phishscore=0 mlxscore=0 bulkscore=0 suspectscore=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 spamscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2210280090 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747942798256136287?= X-GMAIL-MSGID: =?utf-8?q?1747942798256136287?= |
Series |
objtool: Enable and implement --mcount option on powerpc
|
|
Commit Message
Sathvika Vasireddy
Oct. 28, 2022, 2:33 p.m. UTC
In a subsequent patch, we would want to annotate powerpc assembly functions with SYM_FUNC_START_LOCAL macro. This macro depends on __ALIGN macro. The default expansion of __ALIGN macro is: #define __ALIGN .align 4,0x90 So, override __ALIGN and __ALIGN_STR macros to use the same alignment as that of the existing _GLOBAL macro. Also, do not pad with 0x90, because repeated 0x90s are not a nop or trap on powerpc. Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sathvika Vasireddy <sv@linux.ibm.com> --- arch/powerpc/include/asm/linkage.h | 3 +++ 1 file changed, 3 insertions(+)
Comments
Le 28/10/2022 à 16:33, Sathvika Vasireddy a écrit : > In a subsequent patch, we would want to annotate powerpc assembly functions > with SYM_FUNC_START_LOCAL macro. This macro depends on __ALIGN macro. > > The default expansion of __ALIGN macro is: > #define __ALIGN .align 4,0x90 > > So, override __ALIGN and __ALIGN_STR macros to use the same alignment as > that of the existing _GLOBAL macro. Also, do not pad with 0x90, because > repeated 0x90s are not a nop or trap on powerpc. By the way, do we know what the instruction 0x90909090 is on powerpc ? Is that something valid or not ? > > Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> > Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> > Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> > Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> > Signed-off-by: Sathvika Vasireddy <sv@linux.ibm.com> > --- > arch/powerpc/include/asm/linkage.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/powerpc/include/asm/linkage.h b/arch/powerpc/include/asm/linkage.h > index b71b9582e754..b88d1d2cf304 100644 > --- a/arch/powerpc/include/asm/linkage.h > +++ b/arch/powerpc/include/asm/linkage.h > @@ -4,6 +4,9 @@ > > #include <asm/types.h> > > +#define __ALIGN .align 2 > +#define __ALIGN_STR ".align 2" > + > #ifdef CONFIG_PPC64_ELF_ABI_V1 > #define cond_syscall(x) \ > asm ("\t.weak " #x "\n\t.set " #x ", sys_ni_syscall\n" \
Christophe Leroy <christophe.leroy@csgroup.eu> writes: > Le 28/10/2022 à 16:33, Sathvika Vasireddy a écrit : >> In a subsequent patch, we would want to annotate powerpc assembly functions >> with SYM_FUNC_START_LOCAL macro. This macro depends on __ALIGN macro. >> >> The default expansion of __ALIGN macro is: >> #define __ALIGN .align 4,0x90 >> >> So, override __ALIGN and __ALIGN_STR macros to use the same alignment as >> that of the existing _GLOBAL macro. Also, do not pad with 0x90, because >> repeated 0x90s are not a nop or trap on powerpc. > > By the way, do we know what the instruction 0x90909090 is on powerpc ? > Is that something valid or not ? According to objdump it's: stw r4,-28528(r16) cheers
On Wed, Nov 02, 2022 at 12:35:07PM +0000, Christophe Leroy wrote: > > > Le 28/10/2022 à 16:33, Sathvika Vasireddy a écrit : > > In a subsequent patch, we would want to annotate powerpc assembly functions > > with SYM_FUNC_START_LOCAL macro. This macro depends on __ALIGN macro. > > > > The default expansion of __ALIGN macro is: > > #define __ALIGN .align 4,0x90 > > > > So, override __ALIGN and __ALIGN_STR macros to use the same alignment as > > that of the existing _GLOBAL macro. Also, do not pad with 0x90, because > > repeated 0x90s are not a nop or trap on powerpc. > > By the way, do we know what the instruction 0x90909090 is on powerpc ? > Is that something valid or not ? Please also look at the version that's in tip/x86/core (and next). This stuff should be gone now. include/linux/linkage.h now reads like: #ifndef __ALIGN #define __ALIGN .balign CONFIG_FUNCTION_ALIGNMENT #define __ALIGN_STR __stringify(__ALIGN) #endif
Hi Peter, On 03/11/22 14:18, Peter Zijlstra wrote: > On Wed, Nov 02, 2022 at 12:35:07PM +0000, Christophe Leroy wrote: >> >> Le 28/10/2022 à 16:33, Sathvika Vasireddy a écrit : >>> In a subsequent patch, we would want to annotate powerpc assembly functions >>> with SYM_FUNC_START_LOCAL macro. This macro depends on __ALIGN macro. >>> >>> The default expansion of __ALIGN macro is: >>> #define __ALIGN .align 4,0x90 >>> >>> So, override __ALIGN and __ALIGN_STR macros to use the same alignment as >>> that of the existing _GLOBAL macro. Also, do not pad with 0x90, because >>> repeated 0x90s are not a nop or trap on powerpc. >> By the way, do we know what the instruction 0x90909090 is on powerpc ? >> Is that something valid or not ? > Please also look at the version that's in tip/x86/core (and next). This > stuff should be gone now. > > include/linux/linkage.h now reads like: > > #ifndef __ALIGN > #define __ALIGN .balign CONFIG_FUNCTION_ALIGNMENT > #define __ALIGN_STR __stringify(__ALIGN) > #endif Since the above mentioned changes are not a part of powerpc/merge branch yet, I am retaining this patch for this merge cycle and will post a cleanup patch (to move to using FUNCTION_ALIGNMENT_4B) after the next -rc1. Thanks, Sathvika
diff --git a/arch/powerpc/include/asm/linkage.h b/arch/powerpc/include/asm/linkage.h index b71b9582e754..b88d1d2cf304 100644 --- a/arch/powerpc/include/asm/linkage.h +++ b/arch/powerpc/include/asm/linkage.h @@ -4,6 +4,9 @@ #include <asm/types.h> +#define __ALIGN .align 2 +#define __ALIGN_STR ".align 2" + #ifdef CONFIG_PPC64_ELF_ABI_V1 #define cond_syscall(x) \ asm ("\t.weak " #x "\n\t.set " #x ", sys_ni_syscall\n" \