On Wed, Oct 12, 2022 at 04:34:00PM -0700, Palmer Dabbelt wrote: > On Wed, 12 Oct 2022 14:11:58 PDT (-0700), Conor Dooley wrote: > > On Fri, Aug 12, 2022 at 09:25:23AM +0100, Conor Dooley wrote: > > > On Wed, Aug 10, 2022 at 08:31:38PM -0700, Palmer Dabbelt wrote: > > > > This was recently added to binutils and with any luck will soon be in > > > > Linux, without it sparse will fail when trying to build new kernels on > > > > systems with new toolchains. > > > > > > > > > > In passing while testing the zihintpause one: > > > Tested-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> > > > > Hey Luc, > > Would you be able to take a look at this patch and at > > https://lore.kernel.org/linux-sparse/YvYQSdQBuZGSit2s@wendy/T/#t > > please? They're causing sparse to fail for recent kernels when the > > extensions are used. > > Just kind of thinking out loud here, but: Wee brain dump in response, dunno if I am missing your point & if so please correct me... > > Another option would be to just convert the kernel over to Kconfig-based > ifdefs and ignore the -march stuff in sparse. As per the discussion over > here <https://github.com/riscv/riscv-isa-manual/issues/869> it looks like hmm, gnu tools meetings - are bystanders like myself allowed to attend? I doubt I'd have anything interesting to say, but given the names it seems like a good thing to keep an eye on. To be blunt, if the toolchain people are not clear on what the craic is with how extensions interact how are the rest of us supposed to get it? In my naivety I'd expect that sort of distinction to be clear from the spec docs... By kconfig based, do you mean w/ the sort of thing I was messing with in this patchset: https://lore.kernel.org/linux-riscv/20221006173520.1785507-2-conor@xxxxxxxxxx/ I really don't like having ifdef-ery, seems to just result in missed conditions as the recent Zicbom stuff has shown. Since it's thinking- out-loud o clock - while its not my place to make decisions, I think for future extension patchsets I am going to try and push people towards as few conditionally defined variables etc as possible. I think you said the other day that things like __riscv_zmmul are conditionally defined based on the toolchain supporting them right? That'd make sense since older toolchains wouldn't know they existed... Anyways, what I meant by all that is that instead of ifdef-ery, I'd rather IS_ENABLED() with unconditionally {defined,defined} variables so that we don't end up with little pockets of code that end up missed because of some overlapping extension ifdef hell. Upstream seems to have a lot of people that run bells & whistles toolchains with the new & shiny toys available or the standard riscv-gnu-toolchain builds of something significantly older. I'd just be a little worried about potentially having poor coverage of some odd combinations of things with #ifdefs. > we're going to end up with different string->behavior mappings for user-mode > vs privileged software and compilers will be expected to follow the > user-mode mappings, so we'll probably have to do this at some point anyway. Could you explain this one a little more? Even after reading that issue I am a little unsure what you mean by different string->behaviour mappings. Something along the lines of some Zfoo extension could deny user-mode software from using certain instructions but in kernel-land we would want to (or need to?) use those instructions? > That would mean sparse only works right for Linux, I'm not sure if that's > the design point today or not. If that's an issue we could still convert > Linux over and then just have some sort of "--sparse-ignore-march-on-riscv" Do we ignore march, or could we just chop the string after the single letter extensions? I am not up on how much of (if any) of the march string is/would ever be used. I had a quick look at target-riscv.c and it seems we just use it to predefine __riscv_foo & set xlen. Does that mean if we used ifdef-ery or IS_ENABLED to gate features we could avoid having to use new __riscv_foo symbols and therefore not have to predefine them in sparse? Maybe I am misunderstanding - something, something out of my depth... > argument so we don't keep coupling kernel builds to sparse updates. There's > going to be a ton of new extensions so this kind of thing is just going to > keep happening. Yeah, it'd be nice to avoid having to deal with new march updates constantly, especially since we cannot expect everyone to run ToT sparse either. The current situation makes me wonder who outside the pair of us is even running sparse in the first place? Thanks, Conor. > > > > Signed-off-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx> > > > > --- > > > > target-riscv.c | 4 ++++ > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/target-riscv.c b/target-riscv.c > > > > index 217ab7e8..db0f7e57 100644 > > > > --- a/target-riscv.c > > > > +++ b/target-riscv.c > > > > @@ -19,6 +19,7 @@ > > > > #define RISCV_GENERIC (RISCV_MUL|RISCV_DIV|RISCV_ATOMIC|RISCV_FPU) > > > > #define RISCV_ZICSR (1 << 10) > > > > #define RISCV_ZIFENCEI (1 << 11) > > > > +#define RISCV_ZICBOM (1 << 12) > > > > > > > > static unsigned int riscv_flags; > > > > > > > > @@ -41,6 +42,7 @@ static void parse_march_riscv(const char *arg) > > > > { "c", RISCV_COMP }, > > > > { "_zicsr", RISCV_ZICSR }, > > > > { "_zifencei", RISCV_ZIFENCEI }, > > > > + { "_zicbom", RISCV_ZICBOM }, > > > > }; > > > > int i; > > > > > > > > @@ -131,6 +133,8 @@ static void predefine_riscv(const struct target *self) > > > > predefine("__riscv_zicsr", 1, "1"); > > > > if (riscv_flags & RISCV_ZIFENCEI) > > > > predefine("__riscv_zifencei", 1, "1"); > > > > + if (riscv_flags & RISCV_ZICBOM) > > > > + predefine("__riscv_zicbom", 1, "1"); > > > > > > > > if (cmodel) > > > > predefine_strong("__riscv_cmodel_%s", cmodel); > > > > -- > > > > 2.34.1 > > > > > > > >
