Messages in this thread | | | From | Arnd Bergmann <> | Date | Mon, 17 Jun 2019 17:10:32 +0200 | Subject | Re: [PATCH] arm64/sve: fix genksyms generation |
| |
On Mon, Jun 17, 2019 at 4:59 PM Alex Bennée <alex.bennee@linaro.org> wrote: > Arnd Bergmann <arnd@arndb.de> writes: > > On Mon, Jun 17, 2019 at 1:26 PM Will Deacon <will.deacon@arm.com> wrote: > >> On Mon, Jun 17, 2019 at 12:42:11PM +0200, Arnd Bergmann wrote: > >> I suspect I need to figure out what genksyms is doing, but I'm nervous > >> about exposing this as an array type without understanding whether or > >> not that has consequences for its operation. > > > > The entire point is genksyms is to ensure that types of exported symbols > > are compatible. To do this, it has a limited parser for C source code that > > understands the basic types (char, int, long, _Bool, etc) and how to > > aggregate them into structs and function arguments. This process has > > always been fragile, and it clearly breaks when it fails to understand a > > particular type. > > Shouldn't the solution for this be to fix genksyms to be less fragile > and more understanding? The code base doesn't seem to be full of these > sorts of ifdef workarounds.
It is one of the things I tried before I got to the version I send. Unfortunately the genksyms codebase is a big complex and I quickly got lost in it.
You're welcome to volunteer fixing it though. My main problem was that I couldn't even find out which types exactly are supported, as __uint128_t is not even in the gcc documentation. "unsigned __int128" is a documented type, but is also not in genksyms.
Arnd
| |