1
0
Fork 0
Commit Graph

6 Commits (989782dcdc91a5e6d5999c7a52a84a60a0811e56)

Author SHA1 Message Date
Linus Torvalds 3aea311c1b genksyms: fix gperf removal conversion
I had stupidly missed one special use of 'is_reserved_word()' when I
converted the code to avoid gperf.

I had changed that function to return the token ID directly rather than
a pointer to the token descriptor structure, but that meant that the
test for "is this a reserved word" changed from checking the return
value against NULL, to checking that it wasn't negative.

And while I had converted the main token parser over, I missed the
special case of the typeof phrase handling.  And since our dependency
chain for genksyms does not include the genksyms program itself
changing, my kernel rebuild didn't show the problem.

Fixes: bb3290d916 ("Remove gperf usage from toolchain")
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-08 14:32:34 -07:00
Linus Torvalds bb3290d916 Remove gperf usage from toolchain
It turns out that gperf-3.1 changed types in the generated code in ways
that aren't even trivially detectable without having to generate a test-file.

It's just not worth using tools and libraries from clowns that don't
understand or care about compatibility.  So get rid of gperf.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-08-19 11:02:53 -07:00
Michal Marek 5c6f3225d0 kbuild: Regenerate genksyms lexer
Update the lexer after 4fab91605a ("kbuild: genksyms fix for typeof
handling").

Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-25 20:03:51 +02:00
Jan Beulich dc53324060 genksyms: fix typeof() handling
Recent increased use of typeof() throughout the tree resulted in a
number of symbols (25 in a typical distro config of ours) not getting a
proper CRC calculated for them anymore, due to the parser in genksyms
not coping with several of these uses (interestingly in the majority of
[if not all] cases the problem is due to the use of typeof() in code
preceding a certain export, not in the declaration/definition of the
exported function/object itself; I wasn't able to find a way to address
this more general parser shortcoming).

The use of parameter_declaration is a little more relaxed than would be
ideal (permitting not just a bare type specification, but also one with
identifier), but since the same code is being passed through an actual
compiler, there's no apparent risk of allowing through any broken code.

Otoh using parameter_declaration instead of the ad hoc
"decl_specifier_seq '*'" / "decl_specifier_seq" pair allows all types to
be handled rather than just plain ones and pointers to plain ones.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-03 16:20:52 -07:00
Michal Marek 0359de7dd5 genksyms: Regenerate lexer and parser 2011-10-11 12:07:05 +02:00
Arnaud Lacombe 58ef81c5cf genksym: regen parser
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2011-06-09 14:04:42 -04:00