kernel/linux.git/scripts/genksyms/lex.l, branch v6.18.21

genksyms: factor out APP for the ST_NORMAL state

2025-03-15T12:16:21+00:00

For the ST_NORMAL state, APP is called regardless of the token type. Factor it out. Signed-off-by: Masahiro Yamada

genksyms: fix syntax error for builtin (u)intx_t types

2025-01-26T22:44:16+00:00

genksyms: fix syntax error for attribute after 'struct'

2025-01-18T00:11:47+00:00

A longstanding issue with genksyms is that it has hidden syntax errors. When a syntax error occurs, yyerror() is called. However, error_with_pos() is a no-op unless the -w option is provided. You can observe syntax errors by manually passing the -w option. For example, with CONFIG_MODVERSIONS=y on v6.13-rc1: $ make -s KCFLAGS=-D__GENKSYMS__ arch/x86/kernel/cpu/mshyperv.i $ cat arch/x86/kernel/cpu/mshyperv.i | scripts/genksyms/genksyms -w [ snip ] ./arch/x86/include/asm/svm.h:122: syntax error The syntax error occurs in the following code in arch/x86/include/asm/svm.h: struct __attribute__ ((__packed__)) vmcb_control_area { [ snip ] }; The issue arises from __attribute__ immediately after the 'struct' keyword. This commit allows the 'struct' keyword to be followed by attributes. The lexer must be adjusted because dont_want_brace_phase should not be decremented while processing attributes. Signed-off-by: Masahiro Yamada Acked-by: Nicolas Schier

genksyms: fix 6 shift/reduce conflicts and 5 reduce/reduce conflicts

2025-01-18T00:11:38+00:00

The genksyms parser has ambiguities in its grammar, which are currently suppressed by a workaround in scripts/genksyms/Makefile. Building genksyms with W=1 generates the following warnings: YACC scripts/genksyms/parse.tab.[ch] scripts/genksyms/parse.y: warning: 9 shift/reduce conflicts [-Wconflicts-sr] scripts/genksyms/parse.y: warning: 5 reduce/reduce conflicts [-Wconflicts-rr] scripts/genksyms/parse.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples The comment in the parser describes the current problem: /* This wasn't really a typedef name but an identifier that shadows one. */ Consider the following simple C code: typedef int foo; void my_func(foo foo) {} In the function parameter list (foo foo), the first 'foo' is a type specifier (typedef'ed as 'int'), while the second 'foo' is an identifier. However, the lexer cannot distinguish between the two. Since 'foo' is already typedef'ed, the lexer returns TYPE for both instances, instead of returning IDENT for the second one. To support shadowed identifiers, TYPE can be reduced to either a simple_type_specifier or a direct_abstract_declarator, which creates a grammatical ambiguity. Without analyzing the grammar context, it is very difficult to resolve this correctly. This commit introduces a flag, dont_want_type_specifier, which allows the parser to inform the lexer whether an identifier is expected. When dont_want_type_specifier is true, the type lookup is suppressed, and the lexer returns IDENT regardless of any preceding typedef. After this commit, only 3 shift/reduce conflicts will remain. Signed-off-by: Masahiro Yamada Acked-by: Nicolas Schier

genksyms: remove useless case DOTS

2021-02-16T03:01:45+00:00

This switch statement does not list out all the cases. Since the 'default' covers all the rest, the 'DOTS' case is unneeded. Signed-off-by: Masahiro Yamada

genksyms: remove dead code for ST_TABLE_*

2021-02-16T03:01:45+00:00

No one sets lexstate to ST_TABLE_*. It is is very old code, and I do not know what was the plan at that time. Let's remove the dead code. Signed-off-by: Masahiro Yamada

genksyms: make source_file a local variable in lexer

2021-02-16T03:01:44+00:00

This is only used in yylex() in lex.l Signed-off-by: Masahiro Yamada

genksyms: Ignore module scoped _Static_assert()

2020-12-21T04:57:08+00:00

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 Acked-by: Nick Desaulniers Signed-off-by: Masahiro Yamada

genksyms: convert to SPDX License Identifier for lex.l and parse.y

2019-09-14T02:40:13+00:00

I used the C comment style (/* ... */) for the flex and bison files as in Kconfig (scripts/kconfig/{lexer.l,parser.y}) Signed-off-by: Masahiro Yamada

genksyms: fix gperf removal conversion

2017-09-08T21:32:34+00:00

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: bb3290d91695 ("Remove gperf usage from toolchain") Reported-by: Masahiro Yamada Signed-off-by: Linus Torvalds