Disable modpost warnings for linkonce sections

My build gives lots of warnings like

WARNING: sound/core/snd.o (.gnu.linkonce.wi.mpspec_def.h.30779716): unexpected section name.
The (.[number]+) following section name are ld generated and not expected.
Did you forget to use "ax"/"aw" in a .S file?
Note that for example <linux/init.h> contains
section definitions for use in .S files.

But for .linkonce. duplicated sections are actually ok and expected.
So just disable the warning for this case.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Only modules that has other MODULE_* content
shall have the MODULE_LICENSE() tag.

This fixes allmodconfig build on my box.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

This patch adds a new command line option -E to modpost, expecting a symbol
file as an argument which is read prior to symbol processing. -E can be
supplied multiple times for as many files as is needed.

When building kernel modules that depend on other modules not in the main
kernel tree, modpost complains about undefined symbols:
# make -C /path/to/linux/kernel M=/path/to/my/module
...
Building modules, stage 2.
....
WARNING: "rt_copy_buf" [/home/rich/osc_etl_rtw/osc_kmod.ko] undefined!
...etc

This situation occurs when modpost processes the new module's symbols. When
it finds symbols not exported by the mainline kernel, it issues this warning.

The patch adds a new command line option -e to modpost which expects a symbol
file as an argument. The symbols listed in this file are added to modpost's
symbol tables during startup. -e can be supplied as often as required.

This patch works together with the second patch. It introduces a new make
variable, KBUILD_EXTRA_SYMBOLS, which is used when calling modpost.

Signed-off-by: Richard Hacker <lerichi@gmx.net>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Adrian Bunk suggested a build time check for
missing MODULE_LICENSE annotation in modules.
The build time check is fatal as we really
want this fixed for all modules.
In-tree modules should all have been fixed up by now.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Adrian Bunk <bunk@kernel.org>

The module alias support in the kernel have a consistency
check where it is checked that the size of a structure
in the kernel and on the build host are the same.
For cross builds this check does not make sense so detect
when we do cross builds and silently skip the check in these
situations.
This fixes a build bug for a wireless driver when cross building
for arm.

Acked-by: Michael Buesch <mb@bu3sch.de>
Tested-by: Gordon Farquharson <gordonfarquharson@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: stable@kernel.org

XXXINIT_TO_INIT and XXXEXIT_TO_EXIT warnings use the reversed symbol name order
in the suggestion, e.g.:

    WARNING: vmlinux.o(.meminit.text+0x36c): Section mismatch in reference from the function free_area_init_core() to the function .init.text:setup_usemap()
    The function __meminit free_area_init_core() references
    a function __init setup_usemap().
    If free_area_init_core is only used by setup_usemap then
    annotate free_area_init_core with a matching annotation.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

This adds some new magic in the MODPOST phase for CONFIG_MARKERS.  Analogous
to the Module.symvers file, the build will now write a Module.markers file
when CONFIG_MARKERS=y is set.  This file lists the name, defining module, and
format string of each marker, separated by \t characters.  This simple text
file can be used by offline build procedures for instrumentation code,
analogous to how System.map and Module.symvers can be useful to have for
kernels other than the one you are running right now.

The strings are made easy to extract by having the __trace_mark macro define
the name and format together in a single array called __mstrtab_* in the
__markers_strings section.  This is straightforward and reliable as long as
the marker structs are always defined by this macro.  It is an unreasonable
amount of hairy work to extract the string pointers from the __markers section
structs, which entails handling a relocation type for every machine under the
sun.

Mathieu :
- Ran through checkpatch.pl

Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: David Smith <dsmith@redhat.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

modpost: Use warn() for announcing section mismatches, for easy grepping for
warnings in build logs.

Also change an existing call from fprintf() to warn() while we're at it.

Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

If we cannot determine the symbol then print
(unknown) to hint the reader that we failed to
find the symbol.
This happens with REL relocation records
in arm object files.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

We have several legitimate uses where we export symbols
annotated with one of:
__devinit, __cpuinit, __meminit and their exit counterpart.
So let's stop warning about those being exported in favour
of adding all sorts of workaround to silence the warning.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>