genksyms needs to know when a symbol must have a "_" prefex as is
true for a few architectures.
Pass $(ARCH) as commandline argument and hardcode what architectures that
needs this info.
Previous attemt to take it from elfconfig.h was br0ken since elfconfig.h
is a generated file.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The scripts/genksyms/genksyms.c uses hardcoded "__crc_" prefix for
crc symbols in kernel and modules. The prefix should be replaced by
"MODULE_SYMBOL_PREFIX##__crc_" otherwise there will be warnings when
MODULE_SYMBOL_PREFIX is not NULL.
I am sorry my last patch for this issue is actually wrong. I revert
it in this patch.
Signed-off-by: Luke Yang <luke.adi@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Ignore all files generated from *_shipped files, plus a few others.
Signed-off-by: Brian Gerst <bgerst@didntduck.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Generate _shipped files so the genksyms change in previous commit is enabled.
The files are generated with latest versions of the tools:
bison (GNU Bison) 2.0
flex version 2.5.4
GNU gperf 3.0.1
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
This is a one-line change to parse.y.
To take advantage of this the scripts/genksyms/*_shipped files needs to
be rebuild - this is the next patch.
When a .c file contains:
DEFINE_PER_CPU(struct foo_s *, bar);
the .cpp output looks like:
__attribute__((__section__(".data.percpu"))) __typeof__(struct foo_s *) per_cpu__bar;
With the existing parse.y, the value inside the paranthesis of
__typeof__() does not evaluate as a type_specifier and therefore
per_cpu__bar does not get assigned a type for genksyms which results in
the EXPORT_PER_CPU_SYMBOL() not generating a CRC value.
I have compared the Modules.symvers with and without this
patch and for ia64's defconfig, the only change is:
Before 0x00000000 per_cpu____sn_nodepda vmlinux
After 0x9d3f3faa per_cpu____sn_nodepda vmlinux
per_cpu____sn_nodepda was the original source of my problems.
Signed-off-by: Robin Holt <holt@sgi.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
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!
