From: Palmer Dabbelt <palmer@dabbelt.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: mkl@pengutronix.de, aurelien@aurel32.net, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Kito Cheng <kito.cheng@gmail.com>, Paul Walmsley <paul.walmsley@sifive.com>, aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, linux-sparse@vger.kernel.org, ukl@pengutronix.de, luc.vanoostenryck@gmail.com Subject: Re: [PATCH] riscv: fix build with binutils 2.38 Date: Thu, 31 Mar 2022 12:42:36 -0700 (PDT) [thread overview] Message-ID: <mhng-7e447636-2324-406b-9cfc-e5cf766b1737@palmer-mbp2014> (raw) In-Reply-To: <CAHk-=wjnuMD091mNbY=fRm-qFyhMjbtfiwkAFKyFehyR8bPB5A@mail.gmail.com> 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@pengutronix.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.
WARNING: multiple messages have this Message-ID (diff)
From: Palmer Dabbelt <palmer@dabbelt.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: mkl@pengutronix.de, aurelien@aurel32.net, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Kito Cheng <kito.cheng@gmail.com>, Paul Walmsley <paul.walmsley@sifive.com>, aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, linux-sparse@vger.kernel.org, ukl@pengutronix.de, luc.vanoostenryck@gmail.com Subject: Re: [PATCH] riscv: fix build with binutils 2.38 Date: Thu, 31 Mar 2022 12:42:36 -0700 (PDT) [thread overview] Message-ID: <mhng-7e447636-2324-406b-9cfc-e5cf766b1737@palmer-mbp2014> (raw) In-Reply-To: <CAHk-=wjnuMD091mNbY=fRm-qFyhMjbtfiwkAFKyFehyR8bPB5A@mail.gmail.com> 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@pengutronix.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. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-03-31 19:42 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-26 17:14 [PATCH] riscv: fix build with binutils 2.38 Aurelien Jarno 2022-01-26 17:14 ` Aurelien Jarno 2022-01-28 10:05 ` Alexandre Ghiti 2022-01-28 10:05 ` Alexandre Ghiti 2022-02-10 17:40 ` Palmer Dabbelt 2022-02-10 17:40 ` Palmer Dabbelt 2022-02-10 17:56 ` Greg KH 2022-02-10 17:56 ` Greg KH 2022-03-31 10:32 ` Marc Kleine-Budde 2022-03-31 10:32 ` Marc Kleine-Budde 2022-03-31 10:39 ` Marc Kleine-Budde 2022-03-31 10:39 ` Marc Kleine-Budde 2022-03-31 10:51 ` Marc Kleine-Budde 2022-03-31 10:51 ` Marc Kleine-Budde 2022-03-31 17:05 ` Aurelien Jarno 2022-03-31 17:05 ` Aurelien Jarno 2022-03-31 18:16 ` Linus Torvalds 2022-03-31 18:16 ` Linus Torvalds 2022-03-31 19:42 ` Palmer Dabbelt [this message] 2022-03-31 19:42 ` Palmer Dabbelt 2022-04-01 6:53 ` Marc Kleine-Budde 2022-04-01 6:53 ` Marc Kleine-Budde 2022-04-01 17:14 ` Linus Torvalds 2022-04-01 17:14 ` Linus Torvalds 2022-04-01 17:55 ` Palmer Dabbelt 2022-04-01 17:55 ` Palmer Dabbelt 2022-02-14 5:28 Khem Raj 2022-02-17 9:34 ` Leo Liang 2022-02-14 5:31 Khem Raj 2022-02-14 5:33 Khem Raj
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=mhng-7e447636-2324-406b-9cfc-e5cf766b1737@palmer-mbp2014 \ --to=palmer@dabbelt.com \ --cc=aou@eecs.berkeley.edu \ --cc=aurelien@aurel32.net \ --cc=kito.cheng@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=linux-sparse@vger.kernel.org \ --cc=luc.vanoostenryck@gmail.com \ --cc=mkl@pengutronix.de \ --cc=paul.walmsley@sifive.com \ --cc=stable@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=ukl@pengutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.