From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34515 invoked by alias); 28 Apr 2016 10:58:48 -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 34480 invoked by uid 89); 28 Apr 2016 10:58:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:mail-db, Hx-languages-length:2216, positions, site X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Apr 2016 10:58:37 +0000 Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0077.outbound.protection.outlook.com [213.199.154.77]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-25-cO_fwnhARhOklRz22hnrGg-1; Thu, 28 Apr 2016 11:58:31 +0100 Received: from [10.2.206.73] (217.140.96.140) by HE1PR08MB1099.eurprd08.prod.outlook.com (10.166.87.145) with Microsoft SMTP Server (TLS) id 15.1.477.8; Thu, 28 Apr 2016 10:58:28 +0000 Message-ID: <5721ECD1.6090708@arm.com> Date: Thu, 28 Apr 2016 10:58:00 -0000 From: Szabolcs Nagy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Maxim Kuvyrkov CC: , Torsten Duwe , Li Bin , Jiri Kosina , GCC Patches , Marcus Shawcroft , Takahiro Akashi Subject: Re: [PATCH] add -fprolog-pad=N option to c-family References: <20160427152217.GA2637@suse.de> <5720E81D.9060409@arm.com> <7134BE21-ACFB-4C45-871A-FADFA2973040@linaro.org> In-Reply-To: <7134BE21-ACFB-4C45-871A-FADFA2973040@linaro.org> X-ClientProxiedBy: HE1PR02CA0060.eurprd02.prod.outlook.com (10.163.170.28) To HE1PR08MB1099.eurprd08.prod.outlook.com (10.166.87.145) X-MS-Office365-Filtering-Correlation-Id: 3d0c863e-1eaa-473d-7c97-08d36f54081b X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB1099;2:VqWqTMoFWRdbEIQN57oCkPH++hOuEdeftqz3+gOVMHJ+oXQ6Nr1xZHjZy4M2SB0okPn8skwhKnx4oLWEQVpir19TVdQTIzBpLLIrkRSblbFdoL4cBe0ov/ZlkRRnfiYbF1hwT1FBoyATZPWtMumVzuDgz0ykvZ54UwpG91598KGHEp4ne9Q7B/cnHKdCAwUz;3:bb3Ly7xR8Z11kBapDS5S4yoWpOcd3uO2y7USpIDWuz2Kke2V3HGoDkaC0OC3hRAfp3UZmNJm/DAzw0PTvWthNUJtZxKWyBnTiwXYSB+dQ9P7tp2Ke5pKUVhUUQL8K2Vr X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR08MB1099; X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB1099;25:mNHLqffPrd68JUgOViavEMSHMHytzN3xPctm7GAYCRhI4ZjbviRUwConhhuY2TV0ErxBKK2fZ5Xg66LteG8xLlosSVQQ+DV/YPHc9h+5HvMmTkEP7vWQLU+1W1lj4rL7mBrTTyebocurqw9o2sWOtnSKiRINwFfKZ7ojeN93Goo+5Gfkk1hyszu5m62l+6fGyWLUF3qfHjathiGiW0ivne3p12kw4e5n4wAdh3ebiVvZjd69TQJLhmZrN1KqgZX8GlgpWvNlyU+kciowwfhlRcvMbVSXyhNrCKAq1ToEE0SzV3OyW6LXV2iR4v+acc7EBo0x4TV9qULpFKLeF1VMxoq7dXDfPDQ9AiBHgkJG3k9HRfKRJpVQyvcizOWOqDBuiSVEp28Yfb1WAFRhZ7+WuV2azKCe5pnoVUH/ZtygL0cn/HqN4vwsx917RjEFqQL7Gd6c0M00N1O2zr5B3Htu8HnQl18ZzBonVAEdkyTGQNDA8IPE+dn6kxQ3+3Bhhss+LEq8k5xGr3maPXwW2VIWxjAPB4GSbOKOxArSSEjINUP8JM2G5sd5eznT+3ujVmDfXw+LK6zRE0XkLNtX0GAaz2Gbk+Ffw9CR5+GZPU0AsMZ9cGj3NJ4Dww4fmTbi2Tuyi3H1w9soG2dPPcXqM2v6SA==;20:MQu8D1x3mPmZSuiBkEO2n+aMoPLPaVw4RK4OZRTyOFFsdzmqkOtBnaLttCheu8C3jwu5NbqkuCTDFXkABEIqpa9kLDoDV323C0b/o4A+x1+iVhiv8c47u6eztZDFv08X5AtHku0Go8TkXATZkDZsbj39bs0uvS8WPqJ6OBXbjnY= NoDisclaimer: True X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:HE1PR08MB1099;BCL:0;PCL:0;RULEID:;SRVR:HE1PR08MB1099; X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB1099;4:ET8k2bNphpF6MrM5hxGYiYK2vc25WMTdPwvKoJRBqWi4G9qperBFHWVDwfjdpy6uq5LxwR+UKZPGqaV1zY9QL23v1tDh035o23EeM7icgkY+ViFXktpgzfzya0yOXK1f7p1R01CcOfjISjnGyVnnb66YTKdzhsFaswXbSPpQ48pRJuuBJY7A++roFNsspjwhRiCJgbtG+0UmF8cvfB0iJNyfCidS0LNaAobNt+W+3I7KyfUA1Cvzx8EyzLbeVKmacmfGNKqv8twc5ScsAAwhZnPsGsAoChiMNWP4YAtSnVuafDBeRgS9rxsrqryRR3SzlVih9PMhuGIm4L8AAsOxDtol92oTlv72KmKAdeZexsKUeg5UdQIQnurNiZYkyfKB68RUPHc08mtc4aRfErrNCfhJAf83hg5ZUf5ZrM9Qke4= X-Forefront-PRVS: 0926B0E013 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(6049001)(24454002)(377454003)(47776003)(50466002)(4001350100001)(64126003)(5008740100001)(80316001)(19580405001)(83506001)(19580395003)(189998001)(77096005)(23746002)(81166005)(36756003)(33656002)(54356999)(2906002)(42186005)(65816999)(50986999)(76176999)(87266999)(5004730100002)(86362001)(110136002)(59896002)(2950100001)(65956001)(65806001)(66066001)(6116002)(92566002)(1096002)(3846002)(230700001)(586003)(4326007);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR08MB1099;H:[10.2.206.73];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;HE1PR08MB1099;23:HmQh1laykNv40KyDlobvZcXZMMWTU5ZqNqruU?= =?Windows-1252?Q?UjrUo+3V4T40MbkQZ7+BFjelCB4XvV8WOlKxt5EiHPiQUKhnk0B/33En?= =?Windows-1252?Q?F4XXBl0YR+T6PSCPaZ/RBLlfLkv/+/5qXHEDKoa75sSbnQGtE1C7txSw?= =?Windows-1252?Q?DKBGhvi6WCvlhsUBZmHM5QKDtMAC5PeojPEE/4JUtWInT8IsneBEWQq/?= =?Windows-1252?Q?2RdKbf5bx2U+X8u5NHEQ2bJAF4rAhfYn91TccSPFiQQ4x7UOeb5BMMac?= =?Windows-1252?Q?IZL33JxlEaSxHdAxOLYj/XHSebzS7/bHHmDGKyRHQGjki4In18DoTBPc?= =?Windows-1252?Q?Ce3NC2q13+IfsEm8SM386vyBFBLK/gd2aDPP8yVwsKczdmqKqXsNr49o?= =?Windows-1252?Q?nDv2u5LQ4Knyh9GbuByYkyTP7UU6InHihbPncx8lvB0irzQVy7rKgXjs?= =?Windows-1252?Q?kAi5TQqMg2isvvfoXJdglb8s9ZVNHKUMPwykCmC+S7dU5z3LMZHrH7Z4?= =?Windows-1252?Q?4wFZ6tqX/QIJjsKTYd1rrKaxRotCIGm1Vya5PAIcwmIE3AOhx+O9skmG?= =?Windows-1252?Q?oocLdgRp86vqcvoWq87FyMQDVXec3SSy95YLit2jfw8skR+lDhYD+3mC?= =?Windows-1252?Q?xE4GxBYbh/QjIUopYZ7OfxXJVTMuAWft8Yo0XSvscV2lsbloi8TzVc1x?= =?Windows-1252?Q?7lY+ACPPTaGCu4UolcgV3eyEV+7QSPqNPcyw76Sgpbn9tzHZj0OypBWB?= =?Windows-1252?Q?PCeUWuFXkWAAkmB3Z658darRm+zYvKVydXu1GaxyK1Om3u/xt9hPljil?= =?Windows-1252?Q?XgLVnMQPKMWV/+nDclvaRtZaXK3vngL9T7NhjNVo9AEChSYIlooNyRTt?= =?Windows-1252?Q?T5ocHxntjB3LZW4Grt+TeDOB1V61ztrp24Sd0L5lCF6DdPSl8eSdMj6U?= =?Windows-1252?Q?02Yeaxuf0D7sPUoPP/DxXSe5r9ehXkJ37DHPHGVXNZaAg6By2RpCQ/7B?= =?Windows-1252?Q?ScwXJcl6oCTOZZetUWQGSUCKZVJ8uSTTwYKL6bAvxJ+oFNI36JjLQ8hB?= =?Windows-1252?Q?dxQHrKTcR/XrCD5u1mOwy3y4eM0m6c02i1vVRdVm/5bc1bxn/Y/DVcvN?= =?Windows-1252?Q?5XEcqQZifhGLezkJ4dz7Gd8oRAWsXqcL9+XxJ38bzD5?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR08MB1099;5:nSYKGvGNzx6rb+PldrOXAi8/VrIpIR78fveWVY74GL0dj27Hr/LBOAb+o+AuAWd0TkO8FcnBp0EpOo4D6ufpRairkORDi5qBnOiohbgowSJ+vTob5CghhHzX+omPhMitD5g9OFnc7CDudGECw9pcZA==;24:lUBAjeVvbVaD4JyVNAJFYSoFjK0J3b03bXTiE54OAW82UtcgzD5Jqfn++BYmBVmLgbiQ2lN1VSFkZdyigonT6EsB7aAoeg3W4+SX/4aTZwc=;7:fL1n65OlJR7hgHMP/mJVer0yOIV4xT5j1NYQIeUrFgPqGw8J+GRTGdhtAP9FrRhuNYDE0iXbhOGrFwcGiw/QH6jkLFyJUXb0Q/AoM7QG5VKFLryx+N8R0yIMGhSo8ZVh5HDhR3fjr4CE3pM2r3EdLQABrAAxRmbSCUMOHg39Umh7HyQbv/kO4jnH73cQ/hXC;20:Mo+o5wt13FmbMl8XF5u7KWb3OSHQESU4rH/AM7pjmYTawtx6016oie8tqgClmkRPjvGlvwUFECYubQKiSRuycf3F8P4AQ9up3Su1SmMagJ4gsbmTeVeVga1uJaLPM6ti5bnVPZfxSU+bCUToZ02HgoKqHDbgzZyEQ+J+ZMTW1NA= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2016 10:58:28.8326 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB1099 X-MC-Unique: cO_fwnhARhOklRz22hnrGg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg01793.txt.bz2 On 28/04/16 09:47, Maxim Kuvyrkov wrote: >> On Apr 27, 2016, at 7:26 PM, Szabolcs Nagy wrote: >> >> with -mfentry, by default the user only has to >> implement the fentry call (linux wants nops there, but >> e.g. glibc could use -pg -mfentry for profiling on >> aarch64 and the target specific details are easier to >> document for an -m option than for something general). >=20 > I don't understand your point here, could you elaborate, please? >=20 if we only provide -mfentry then - the kernel can use it (they have tools to nop patch the binary), - others who don't want to fiddle with nops, just have the call, can also use it (e.g. user-space profiling cannot really use something that needs binary patching in case the user prefers -pg -mfentry over the current -pg behaviour). - it's target specific, so the magic abi of the fentry call can be documented by the target according to the specific instruction sequence that is used. (with nop-padding there are psabi and compiler optimization interactions that may be hard to document in a generic way and letting the user figure it out may cause problems later in compiler development.. but i'm just speculating based on the powerpc toc handling and ipa-ra findings.) >> the nop-padding is more general, but the size and >> layout of nops and the call abi will be target >> specific and the user will most likely need to modify >> the binary (to get the right sequence) which needs >> additional tooling. i don't know who might use it >> other than linux (which already has tools to deal with >> -mfentry). >=20 > Right, but this tooling will require minimal (if any) changes > to be adapted to nop-pad approach. If I remember correctly, > recent versions of GCC and kernel for x86_64 generate NOPs, > not the call sequence in the prologs when -mfentry is used. i'm trying to find where this happens in the kernel, but i only see scripts/recordmcount.{c,pl} which are based on nop patching the fentry/mcount call sites. without such call sites the tools have to be implemented differently and the way the kernel records the call site positions might not match the prolog-pad recording.