[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNOfs8Of0Kvp3v7miw5x0Neg5i4egc43bevLV3_rGCNqtA@mail.gmail.com>
Date: Tue, 1 Dec 2020 21:12:57 +0100
From: Marco Elver <elver@...gle.com>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
kasan-dev <kasan-dev@...glegroups.com>,
Masahiro Yamada <masahiroy@...nel.org>,
Joe Perches <joe@...ches.com>
Subject: Re: [PATCH] genksyms: Ignore module scoped _Static_assert()
On Tue, 1 Dec 2020 at 21:00, Nick Desaulniers <ndesaulniers@...gle.com> wrote:
>
> On Tue, Dec 1, 2020 at 7:21 AM Marco Elver <elver@...gle.com> wrote:
> >
> > The C11 _Static_assert() keyword may be used at module scope, and we
> > need to teach genksyms about it to not abort with an error. We currently
> > have a growing number of static_assert() (but also direct usage of
> > _Static_assert()) users at module scope:
> >
> > git grep -E '^_Static_assert\(|^static_assert\(' | grep -v '^tools' | wc -l
> > 135
> >
> > More recently, when enabling CONFIG_MODVERSIONS with CONFIG_KCSAN, we
> > observe a number of warnings:
> >
> > WARNING: modpost: EXPORT symbol "<..all kcsan symbols..>" [vmlinux] [...]
> >
> > When running a preprocessed source through 'genksyms -w' a number of
> > syntax errors point at usage of static_assert()s. In the case of
> > kernel/kcsan/encoding.h, new static_assert()s had been introduced which
> > used expressions that appear to cause genksyms to not even be able to
> > recover from the syntax error gracefully (as it appears was the case
> > previously).
> >
> > Therefore, make genksyms ignore all _Static_assert() and the contained
> > expression. With the fix, usage of _Static_assert() no longer cause
> > "syntax error" all over the kernel, and the above modpost warnings for
> > KCSAN are gone, too.
> >
> > Signed-off-by: Marco Elver <elver@...gle.com>
>
> Ah, genksyms...if only there were a library that we could use to parse
> C code...:P
Hehe -- another usecase for using that library ;-) If only we could
require LLVM be present even when building the rest of the kernel with
GCC.
I guess this works, for now. Until the next new keyword that is used
at module scope...
> Acked-by: Nick Desaulniers <ndesaulniers@...gle.com>
Thanks!
Powered by blists - more mailing lists