genksyms: factor out APP for the ST_NORMAL state

For the ST_NORMAL state, APP is called regardless of the token type.
Factor it out.

Signed-off-by: Masahiro Yamada <[email protected]>

genksyms: fix syntax error for builtin (u)int*x*_t types

A longstanding issue with genksyms is that it has hidden syntax errors.

When a syntax error occurs, yyerror() is called. However,
error_with

genksyms: fix syntax error for builtin (u)int*x*_t types

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, genksyms fails to parse the following code in
arch/arm64/lib/xor-neon.c:

static inline uint64x2_t eor3(uint64x2_t p, uint64x2_t q, uint64x2_t r)
{
[ snip ]
}

The syntax error occurs because genksyms does not recognize the
uint64x2_t keyword.

This commit adds support for builtin types described in Arm Neon
Intrinsics Reference.

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Nicolas Schier <[email protected]>

show more ...

genksyms: fix syntax error for attribute after 'struct'

A longstanding issue with genksyms is that it has hidden syntax errors.

When a syntax error occurs, yyerror() is called. However,
error_with_

genksyms: fix syntax error for attribute after 'struct'

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 <[email protected]>
Acked-by: Nicolas Schier <[email protected]>

show more ...

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

The genksyms parser has ambiguities in its grammar, which are currently
suppressed by a workaround in scripts/genksyms/Makefile.

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

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 <[email protected]>
Acked-by: Nicolas Schier <[email protected]>

show more ...

genksyms: remove useless case DOTS

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 <masah

genksyms: remove useless case DOTS

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 <[email protected]>

show more ...

genksyms: remove dead code for ST_TABLE_*

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: Ma

genksyms: remove dead code for ST_TABLE_*

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 <[email protected]>

show more ...

genksyms: make source_file a local variable in lexer

This is only used in yylex() in lex.l

Signed-off-by: Masahiro Yamada <[email protected]>

genksyms: Ignore module scoped _Static_assert()

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 g

genksyms: Ignore module scoped _Static_assert()

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

show more ...

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

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

Signed-off-

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

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 <[email protected]>

show more ...

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 dir

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

show more ...

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

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 <[email protected]>

show more ...

kbuild: genksyms fix for typeof handling

The tokenizer misses counting an open-parenthesis when parsing a
non-trivial typeof beginning with an open-parenthesis. This function
in include/linux/ceph/l

kbuild: genksyms fix for typeof handling

The tokenizer misses counting an open-parenthesis when parsing a
non-trivial typeof beginning with an open-parenthesis. This function
in include/linux/ceph/libceph.h

static type *lookup_##name(struct rb_root *root,
typeof(((type *)0)->keyfld) key)

When instantiated in net/ceph/mon_client.c, causes subsequent symbols
including an EXPORT_SYMBOL in that file to be lost.

Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Michal Marek <[email protected]>

show more ...

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 t

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 <[email protected]>
Cc: Michal Marek <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

genksyms: Do not expand internal types

Consider structures, unions and enums defined in the source file as
internal and do not expand them. This way, changes to e.g. struct
serial_private in drivers

genksyms: Do not expand internal types

Consider structures, unions and enums defined in the source file as
internal and do not expand them. This way, changes to e.g. struct
serial_private in drivers/tty/serial/8250_pci.c will not affect the
checksum of the pciserial_* exports.

show more ...

genksyms: migrate parser to implicit rules

Signed-off-by: Arnaud Lacombe <[email protected]>

genksyms: Track changes to enum constants

Enum constants can be used as array sizes; if the enum itself does not
appear in the symbol expansion, a change in the enum constant will go
unnoticed. Exam

genksyms: Track changes to enum constants

Enum constants can be used as array sizes; if the enum itself does not
appear in the symbol expansion, a change in the enum constant will go
unnoticed. Example patch that changes the ABI but does not change the
checksum with current genksyms:

| enum e {
| E1,
| E2,
|+ E3,
| E_MAX
| };
|
| struct s {
| int a[E_MAX];
| }
|
| int f(struct s *s) { ... }
| EXPORT_SYMBOL(f)

Therefore, remember the value of each enum constant and
expand each occurence to <constant> <value>. The value is not actually
computed, but instead an expression in the form
(last explicitly assigned value) + N
is used. This avoids having to parse and semantically understand whole
of C.

Note: The changes won't take effect until the lexer and parser are
rebuilt by the next patch.

Signed-off-by: Michal Marek <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>

show more ...

genksyms: simplify usage of find_symbol()

Allow searching for symbols of an exact type. The lexer does this and a
subsequent patch will add one more usage.

Signed-off-by: Michal Marek <mmarek@suse.

genksyms: simplify usage of find_symbol()

Allow searching for symbols of an exact type. The lexer does this and a
subsequent patch will add one more usage.

Signed-off-by: Michal Marek <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>

show more ...

genksyms: Simplify lexer

The V2_TOKENS state is active all the time.

Signed-off-by: Michal Marek <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>

kbuild: scripts/genksyms/lex.l: add %option noinput

gcc 4.3 correctly determines that input() is unused and gives the
following warning:

<-- snip -->

...
HOSTCC scripts/genksyms/lex.o
scripts

kbuild: scripts/genksyms/lex.l: add %option noinput

gcc 4.3 correctly determines that input() is unused and gives the
following warning:

<-- snip -->

...
HOSTCC scripts/genksyms/lex.o
scripts/genksyms/lex.c:1487: warning: ‘input’ defined but not used
...

<-- snip -->

Fix it by adding %option noinput to scripts/genksyms/lex.l and
regeneration of scripts/genksyms/lex.c_shipped.

Signed-off-by: Adrian Bunk <[email protected]>
Signed-off-by: Sam Ravnborg <[email protected]>

show more ...

kbuild: replace abort() with exit(1)

We have had no use of the coredump file for a long time.
So just exit(1) and avoid coredumping.

Signed-off-by: Sam Ravnborg <[email protected]>

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

show more ...