| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
input file
Renaming hash and lookup functions on the command line would reduces its
genericity. Use the .gperf file to pass this information. Do the same for the
target language.
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
|
|
Despite being unused these should also get a CRC calculated.
Primarily I view this as a consistency thing. But I also think this is
one of the reasons why __crc_* need to be weak (which I think should be
avoided, and hence we should have the goal to eliminate this so that
failure to calculate a proper CRC for a symbol causes the build to fail).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Anibal Monsalve Salazar <anibal@debian.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
|
|
The genksyms keyword gperf hash provides a function is_reserved_word.
genksyms #includes the resulting generated file keywords.c, so the
function gets used only in the same source file that defines it. Mark
is_reserved_word static, and regenerate the corresponding generated
file.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
|
|
This reverts commit ad7a953c522ceb496611d127e51e278bfe0ff483.
And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL")
9bb482476c6c9d1ae033306440c51ceac93ea80c
These stripping patches has caused a set of issues:
1) People have reported compatibility issues with binutils due to
lack of support for `--strip-unneeded-symbols' with objcopy 2.15.92.0.2
Reported by: Wenji
2) ccache and distcc no longer works as expeced
Reported by: Ted, Roland, + others
3) The installed modules increased a lot in size
Reported by: Ted, Davej + others
Reported-by: Wenji Huang <wenji.huang@oracle.com>
Reported-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
Building upon parts of the module stripping patch, this patch
introduces similar stripping for vmlinux when CONFIG_KALLSYMS_ALL=y.
Using CONFIG_KALLSYMS_STRIP_GENERATED reduces the overhead of
CONFIG_KALLSYMS_ALL from 245k/310k to 65k/80k for the (i386/x86-64)
kernels I tested with.
The patch also does away with the need to special case the kallsyms-
internal symbols by making them available even in the first linking
stage.
While it is a generated file, the patch includes the changes to
scripts/genksyms/keywords.c_shipped, as I'm unsure what the procedure
here is.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
Recently the __extension__ keyword has been introduced in the kernel.
Teach genksyms about this keyword so it can generate correct CRC for
exported symbols that uses a symbol marked __extension__.
For now only the typedef variant:
__extension__ typedef ...
is supported.
Later we may add more variants as needed.
This patch contains the actual source file changes. The
following patch will hold modifications to the generated
files (*_shipped) and only after the second patch the fix
has effect.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
This patch adds the ability to mark symbols that will be changed in the
future, so that kernel modules that don't include MODULE_LICENSE("GPL")
and use the symbols, will be flagged and printed out to the system log.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
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!
|
