linux-kernel - Re: Build regressions/improvements in v4.9-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 27 Oct 2016 10:21:16 -0700
From:   Vineet Gupta <vgupta@...opsys.com>
To:     Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
        "thomas.petazzoni@...e-electrons.com" 
        <thomas.petazzoni@...e-electrons.com>
Cc:     "mmarek@...e.cz" <mmarek@...e.cz>, "arnd@...db.de" <arnd@...db.de>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        Claudiu Zissulescu <Claudiu.Zissulescu@...opsys.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "linux-snps-arc@...ts.infradead.org" 
        <linux-snps-arc@...ts.infradead.org>
Subject: Re: Build regressions/improvements in v4.9-rc1

+CC Claudiu

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 ?

-Vineet