Commit Graph

9 Commits

Author SHA1 Message Date
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 2c5925d6b7 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.
2011-10-11 12:00:39 +02:00
Arnaud Lacombe 880f4499bb genksyms: migrate parser to implicit rules
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
2011-06-09 14:04:41 -04:00
Michal Marek e37ddb8250 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 <mmarek@suse.cz>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2011-03-17 15:13:56 +01:00
Michal Marek 01762c4ec5 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.cz>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2011-03-17 15:13:55 +01:00
Michal Marek 95f1d639ad genksyms: Simplify lexer
The V2_TOKENS state is active all the time.

Signed-off-by: Michal Marek <mmarek@suse.cz>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2011-03-17 15:13:55 +01:00
Adrian Bunk 11ddad3960 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 <bunk@kernel.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-07-30 22:31:02 +02:00
Sam Ravnborg 6803dc0ea8 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 <sam@ravnborg.org>
2006-06-24 23:46:54 +02:00
Linus Torvalds 1da177e4c3 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!
2005-04-16 15:20:36 -07:00