From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Fri, 28 Oct 2016 12:42:25 +0200 Subject: Build regressions/improvements in v4.9-rc1 In-Reply-To: References: <1476688913-15648-1-git-send-email-geert@linux-m68k.org> <1477561144.2561.19.camel@synopsys.com> List-ID: Message-ID: <4261133.nGEyC6LumW@wuerfel> To: linux-snps-arc@lists.infradead.org On Thursday, October 27, 2016 10:21:16 AM CEST Vineet Gupta wrote: > > On 10/27/2016 02:39 AM, Alexey Brodkin wrote: > > > > And these are functions required by U-Boot (most probably the same is applied to kernel): > > 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX > > This kicks in only at -Os and even there can be inhibited with a toggle. > I don't like it anyways, seems like a costly contraption in terms of microarch > cost of 2 extra long branches for both prologue and epilogue. > > > 2) shifts: __ashldi3, __ashrdi3, __lshrdi3, > > 3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3 > > Note that this list is not constant. I recently had to export another libgcc > symbol for modules, when a customer switched to ARC gnu 2016.03 for supposedly > building the same kernel code. > > > Indeed it is possible to have so-called private libgcc in kernel as well but > > benefit will be only for people building kernels but not user-space because > > in absence of multilibbed toolchain 2 separate toolchains will be required anyways. > > True, but a lot of people only care about builds (and not actually run), so for > them having to carry only one toolchain is an improvement. > > > Still we'll have to pay an additional maintenance price to keep kernel's libgcc in > > sync with the one from gcc. > > True, but libgcc math emulation is likely one off thing. GNU folks will write them > once and we use a snapshot - syncing back changes - if any around major gnu releases. > > So I'm tending to include the libgcc code in kernel. @Arnd, @Claudiu do you know > of any potential licensing issues ? > I'd be surprised if there were any licensing issues, as libgcc is intentionally meant to be included in everything built by gcc, and the architectures that don't link against it tend to have a direct copy. The main advantage of copying libgcc sources into the kernel instead of linking directly to it is probably that you have better control over which functions are actually used, as not everything in libgcc makes sense in kernel space. The most common example is probably the 64-bit division, which is a libgcc function on most architectures, and in the kernel we intentionally don't implement that function in order to catch drivers trying to do that (and change them to either explicit div_u64() or not do a 64-bit division). Another example of a libgcc function you don't want is anything calling abort(), which makes no sense in the kernel. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756263AbcJ1Knh (ORCPT ); Fri, 28 Oct 2016 06:43:37 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:61450 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752419AbcJ1Knf (ORCPT ); Fri, 28 Oct 2016 06:43:35 -0400 From: Arnd Bergmann To: Vineet Gupta Cc: Alexey Brodkin , "thomas.petazzoni@free-electrons.com" , "mmarek@suse.cz" , "peterz@infradead.org" , "mpe@ellerman.id.au" , Claudiu Zissulescu , "linux-kernel@vger.kernel.org" , "geert@linux-m68k.org" , "linux-snps-arc@lists.infradead.org" Subject: Re: Build regressions/improvements in v4.9-rc1 Date: Fri, 28 Oct 2016 12:42:25 +0200 Message-ID: <4261133.nGEyC6LumW@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1476688913-15648-1-git-send-email-geert@linux-m68k.org> <1477561144.2561.19.camel@synopsys.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:VWFA9PLe1Gj0ZAViU+5+TVE2WZtqmPiEkNrO+J6I2nrkCa20Gyb G1SdRUc/M3PsTVdbWUGFuCozSheibNJgxjnltZdxbmH0fEK58xdfXDLYgD5YArjLYKQxu2i El3XwfeQcvw3/wjFV7d0ploS6kKeYWSqs0xb25Bqrz52Bkyc569hO2chpH1+jKHnWKd4OLl i2Mv4+OJd324wbHhB8Yig== X-UI-Out-Filterresults: notjunk:1;V01:K0:uF5RADkVC04=:X82kWqnVGUWMkcWuow9HVb svKx4xdbhD6YCX45FuW/FvexTmawefVI+waWt/blv3GjIrektT8wSawZaFVdpBJ7uvqA+KR6O OfWaQUXnKYC2MHcVSp/lRRkULDIl2aIyYmbIMU/3lEbGwP1IlZgBWkfYARQPAzrjB2YOfR9+0 LQ+zj6HgzpNCotoKS/P2+Sz+TGfQsSu6RWuwce6vxKAAN8pWcTG461EEr4PUXMYcA59X0oQoH XP44rgKD6DTiG4xGJWv9bMCc4YqExSOdD7dTunyENLkOmwABwN3kKRMUKPV5sgHbtbZyp/e9N DV8cD8QoWOrFWV7PDFZA+LbtCI08jalUT3s734QuFVi2pPyoqHsvR+3tjICiy3HFdos4GYs1v u8t2KNvX54vD5tRQByTf6i7Bslqz+ygFYRZTfvlr0HN+eWU/s7jnnshARlChutTR+Rfx7EFNf gpMD88lkyil2vHz66ps34gcY5H6D6VWiijb3xBfk+J6msFPWbT4Gv/YxPYEljRP81+j0zdlsV KgO7exi0+56OOP3/ofzTfwkkaeVfTM0GSNINefMwG2mAm4P3ANHH5EulDfP08YaiqUmDOcDhr NQDlc3cYItbV20WHcv5HtQO/6ISSeCR34zAId2eDHRkx/fk8Fzlgcyor2CL3Tyffvv9MGgDb1 tpQFFNjKpXWCWVEWLeVw3/Gxs54U3/gS0wnjieDZ8eu5LJjuxSNIm2RlMNmlizc/LizwdSyjA W3qM9tswdYczsObf Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, October 27, 2016 10:21:16 AM CEST Vineet Gupta wrote: > > On 10/27/2016 02:39 AM, Alexey Brodkin wrote: > > > > And these are functions required by U-Boot (most probably the same is applied to kernel): > > 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX > > This kicks in only at -Os and even there can be inhibited with a toggle. > I don't like it anyways, seems like a costly contraption in terms of microarch > cost of 2 extra long branches for both prologue and epilogue. > > > 2) shifts: __ashldi3, __ashrdi3, __lshrdi3, > > 3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3 > > Note that this list is not constant. I recently had to export another libgcc > symbol for modules, when a customer switched to ARC gnu 2016.03 for supposedly > building the same kernel code. > > > Indeed it is possible to have so-called private libgcc in kernel as well but > > benefit will be only for people building kernels but not user-space because > > in absence of multilibbed toolchain 2 separate toolchains will be required anyways. > > True, but a lot of people only care about builds (and not actually run), so for > them having to carry only one toolchain is an improvement. > > > Still we'll have to pay an additional maintenance price to keep kernel's libgcc in > > sync with the one from gcc. > > True, but libgcc math emulation is likely one off thing. GNU folks will write them > once and we use a snapshot - syncing back changes - if any around major gnu releases. > > So I'm tending to include the libgcc code in kernel. @Arnd, @Claudiu do you know > of any potential licensing issues ? > I'd be surprised if there were any licensing issues, as libgcc is intentionally meant to be included in everything built by gcc, and the architectures that don't link against it tend to have a direct copy. The main advantage of copying libgcc sources into the kernel instead of linking directly to it is probably that you have better control over which functions are actually used, as not everything in libgcc makes sense in kernel space. The most common example is probably the 64-bit division, which is a libgcc function on most architectures, and in the kernel we intentionally don't implement that function in order to catch drivers trying to do that (and change them to either explicit div_u64() or not do a 64-bit division). Another example of a libgcc function you don't want is anything calling abort(), which makes no sense in the kernel. Arnd