linux-kernel - Re: [PATCH] riscv: fix build with binutils 2.38

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]

Message-ID: <mhng-7e447636-2324-406b-9cfc-e5cf766b1737@palmer-mbp2014>
Date:   Thu, 31 Mar 2022 12:42:36 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
CC:     mkl@...gutronix.de, aurelien@...el32.net,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Kito Cheng <kito.cheng@...il.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, linux-riscv@...ts.infradead.org,
        linux-sparse@...r.kernel.org, ukl@...gutronix.de,
        luc.vanoostenryck@...il.com
Subject:     Re: [PATCH] riscv: fix build with binutils 2.38

On Thu, 31 Mar 2022 11:16:53 PDT (-0700), Linus Torvalds wrote:
> On Thu, Mar 31, 2022 at 3:51 AM Marc Kleine-Budde <mkl@...gutronix.de> wrote:
>>
>> Cc += linux-sparse, Uwe, Luc Van Oostenryck
>>
>> tl;dr:
>>
>> A recent change in the kernel regarding the riscv -march handling breaks
>> current sparse.

Sorry about that, looks like I'm not running sparse as part of my 
testing.  I'll add it, but it might take a bit as I'm assuming there 
will be a bunch of issues it points out.

> Gaah. Normally sparse doesn't even look at the -march flag, but for
> riscv it does, because it's meaningful for the predefined macros.
>
> Maybe that 'die()' shouldn't be so fatal. And maybe add a few more
> extensions (but ignore them) to the parsing.
>
> Something ENTIRELY UNTESTED like the attached.

Converting this to a warning seems reasonable to me, as then we're not 
as coupled to the sparse version.  The current crop of extensions don't 
set anything exciting for Linux, but there are some on the horizon that 
likely will -- hopefully having sparse in my test setup should be 
sufficient to dig those up, though.

As far as the new extension go: "Counters" isn't an ISA extension, and 
"e" defines "__riscv_32e".  It'd also be slightly saner to match on 
"_Zifencei", but that probably doesn't matter (GCC is sufficiently 
strict here).  Looks like there's also some oddities in the sparse ISA 
string parsing, I'll go clean them up as I get it running locally.

We could also stop relying on the compiler's defines, which would avoid 
this problem entirely, but IIRC that was discussed when decided to 
modify sparse in the first place and we went this way (though I don't 
remember why).  That would keep everything inside the kernel.