2011-05-23 12:11:39 -06:00
|
|
|
#ifndef _LINUX_EXPORT_H
|
|
|
|
|
#define _LINUX_EXPORT_H
|
kbuild: allow archs to select link dead code/data elimination
Introduce LD_DEAD_CODE_DATA_ELIMINATION option for architectures to
select to build with -ffunction-sections, -fdata-sections, and link
with --gc-sections. It requires some work (documented) to ensure all
unreferenced entrypoints are live, and requires toolchain and build
verification, so it is made a per-arch option for now.
On a random powerpc64le build, this yelds a significant size saving,
it boots and runs fine, but there is a lot I haven't tested as yet, so
these savings may be reduced if there are bugs in the link.
text data bss dec filename
11169741 1180744 1923176 14273661 vmlinux
10445269 1004127 1919707 13369103 vmlinux.dce
~700K text, ~170K data, 6% removed from kernel image size.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 06:29:20 -06:00
|
|
|
|
2011-05-23 12:11:39 -06:00
|
|
|
/*
|
|
|
|
|
* Export symbols from the kernel to modules. Forked from module.h
|
|
|
|
|
* to reduce the amount of pointless cruft we feed to gcc when only
|
|
|
|
|
* exporting a simple symbol or two.
|
|
|
|
|
*
|
2013-03-14 22:34:17 -06:00
|
|
|
* Try not to add #includes here. It slows compilation and makes kernel
|
|
|
|
|
* hackers place grumpy comments in header files.
|
2011-05-23 12:11:39 -06:00
|
|
|
*/
|
|
|
|
|
|
2013-03-14 22:34:17 -06:00
|
|
|
#define __VMLINUX_SYMBOL(x) x
|
|
|
|
|
#define __VMLINUX_SYMBOL_STR(x) #x
|
2011-05-23 12:11:39 -06:00
|
|
|
|
2013-03-14 22:34:17 -06:00
|
|
|
/* Indirect, so macros are expanded before pasting. */
|
|
|
|
|
#define VMLINUX_SYMBOL(x) __VMLINUX_SYMBOL(x)
|
|
|
|
|
#define VMLINUX_SYMBOL_STR(x) __VMLINUX_SYMBOL_STR(x)
|
|
|
|
|
|
|
|
|
|
#ifndef __ASSEMBLY__
|
2011-05-23 12:11:39 -06:00
|
|
|
struct kernel_symbol
|
|
|
|
|
{
|
|
|
|
|
unsigned long value;
|
|
|
|
|
const char *name;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#ifdef MODULE
|
|
|
|
|
extern struct module __this_module;
|
|
|
|
|
#define THIS_MODULE (&__this_module)
|
|
|
|
|
#else
|
|
|
|
|
#define THIS_MODULE ((struct module *)0)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_MODULES
|
|
|
|
|
|
2016-01-21 23:32:26 -07:00
|
|
|
#if defined(__KERNEL__) && !defined(__GENKSYMS__)
|
2011-05-23 12:11:39 -06:00
|
|
|
#ifdef CONFIG_MODVERSIONS
|
|
|
|
|
/* Mark the CRC weak since genksyms apparently decides not to
|
|
|
|
|
* generate a checksums for some symbols */
|
modversions: treat symbol CRCs as 32 bit quantities
The modversion symbol CRCs are emitted as ELF symbols, which allows us
to easily populate the kcrctab sections by relying on the linker to
associate each kcrctab slot with the correct value.
This has a couple of downsides:
- Given that the CRCs are treated as memory addresses, we waste 4 bytes
for each CRC on 64 bit architectures,
- On architectures that support runtime relocation, a R_<arch>_RELATIVE
relocation entry is emitted for each CRC value, which identifies it
as a quantity that requires fixing up based on the actual runtime
load offset of the kernel. This results in corrupted CRCs unless we
explicitly undo the fixup (and this is currently being handled in the
core module code)
- Such runtime relocation entries take up 24 bytes of __init space
each, resulting in a x8 overhead in [uncompressed] kernel size for
CRCs.
Switching to explicit 32 bit values on 64 bit architectures fixes most
of these issues, given that 32 bit values are not treated as quantities
that require fixing up based on the actual runtime load offset. Note
that on some ELF64 architectures [such as PPC64], these 32-bit values
are still emitted as [absolute] runtime relocatable quantities, even if
the value resolves to a build time constant. Since relative relocations
are always resolved at build time, this patch enables MODULE_REL_CRCS on
powerpc when CONFIG_RELOCATABLE=y, which turns the absolute CRC
references into relative references into .rodata where the actual CRC
value is stored.
So redefine all CRC fields and variables as u32, and redefine the
__CRC_SYMBOL() macro for 64 bit builds to emit the CRC reference using
inline assembler (which is necessary since 64-bit C code cannot use
32-bit types to hold memory addresses, even if they are ultimately
resolved using values that do not exceed 0xffffffff). To avoid
potential problems with legacy 32-bit architectures using legacy
toolchains, the equivalent C definition of the kcrctab entry is retained
for 32-bit architectures.
Note that this mostly reverts commit d4703aefdbc8 ("module: handle ppc64
relocating kcrctabs when CONFIG_RELOCATABLE=y")
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-03 02:54:06 -07:00
|
|
|
#if defined(CONFIG_MODULE_REL_CRCS)
|
|
|
|
|
#define __CRC_SYMBOL(sym, sec) \
|
|
|
|
|
asm(" .section \"___kcrctab" sec "+" #sym "\", \"a\" \n" \
|
2018-05-09 01:23:49 -06:00
|
|
|
" .weak __crc_" #sym " \n" \
|
|
|
|
|
" .long __crc_" #sym " - . \n" \
|
modversions: treat symbol CRCs as 32 bit quantities
The modversion symbol CRCs are emitted as ELF symbols, which allows us
to easily populate the kcrctab sections by relying on the linker to
associate each kcrctab slot with the correct value.
This has a couple of downsides:
- Given that the CRCs are treated as memory addresses, we waste 4 bytes
for each CRC on 64 bit architectures,
- On architectures that support runtime relocation, a R_<arch>_RELATIVE
relocation entry is emitted for each CRC value, which identifies it
as a quantity that requires fixing up based on the actual runtime
load offset of the kernel. This results in corrupted CRCs unless we
explicitly undo the fixup (and this is currently being handled in the
core module code)
- Such runtime relocation entries take up 24 bytes of __init space
each, resulting in a x8 overhead in [uncompressed] kernel size for
CRCs.
Switching to explicit 32 bit values on 64 bit architectures fixes most
of these issues, given that 32 bit values are not treated as quantities
that require fixing up based on the actual runtime load offset. Note
that on some ELF64 architectures [such as PPC64], these 32-bit values
are still emitted as [absolute] runtime relocatable quantities, even if
the value resolves to a build time constant. Since relative relocations
are always resolved at build time, this patch enables MODULE_REL_CRCS on
powerpc when CONFIG_RELOCATABLE=y, which turns the absolute CRC
references into relative references into .rodata where the actual CRC
value is stored.
So redefine all CRC fields and variables as u32, and redefine the
__CRC_SYMBOL() macro for 64 bit builds to emit the CRC reference using
inline assembler (which is necessary since 64-bit C code cannot use
32-bit types to hold memory addresses, even if they are ultimately
resolved using values that do not exceed 0xffffffff). To avoid
potential problems with legacy 32-bit architectures using legacy
toolchains, the equivalent C definition of the kcrctab entry is retained
for 32-bit architectures.
Note that this mostly reverts commit d4703aefdbc8 ("module: handle ppc64
relocating kcrctabs when CONFIG_RELOCATABLE=y")
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-03 02:54:06 -07:00
|
|
|
" .previous \n");
|
2011-05-23 12:11:39 -06:00
|
|
|
#else
|
modversions: treat symbol CRCs as 32 bit quantities
The modversion symbol CRCs are emitted as ELF symbols, which allows us
to easily populate the kcrctab sections by relying on the linker to
associate each kcrctab slot with the correct value.
This has a couple of downsides:
- Given that the CRCs are treated as memory addresses, we waste 4 bytes
for each CRC on 64 bit architectures,
- On architectures that support runtime relocation, a R_<arch>_RELATIVE
relocation entry is emitted for each CRC value, which identifies it
as a quantity that requires fixing up based on the actual runtime
load offset of the kernel. This results in corrupted CRCs unless we
explicitly undo the fixup (and this is currently being handled in the
core module code)
- Such runtime relocation entries take up 24 bytes of __init space
each, resulting in a x8 overhead in [uncompressed] kernel size for
CRCs.
Switching to explicit 32 bit values on 64 bit architectures fixes most
of these issues, given that 32 bit values are not treated as quantities
that require fixing up based on the actual runtime load offset. Note
that on some ELF64 architectures [such as PPC64], these 32-bit values
are still emitted as [absolute] runtime relocatable quantities, even if
the value resolves to a build time constant. Since relative relocations
are always resolved at build time, this patch enables MODULE_REL_CRCS on
powerpc when CONFIG_RELOCATABLE=y, which turns the absolute CRC
references into relative references into .rodata where the actual CRC
value is stored.
So redefine all CRC fields and variables as u32, and redefine the
__CRC_SYMBOL() macro for 64 bit builds to emit the CRC reference using
inline assembler (which is necessary since 64-bit C code cannot use
32-bit types to hold memory addresses, even if they are ultimately
resolved using values that do not exceed 0xffffffff). To avoid
potential problems with legacy 32-bit architectures using legacy
toolchains, the equivalent C definition of the kcrctab entry is retained
for 32-bit architectures.
Note that this mostly reverts commit d4703aefdbc8 ("module: handle ppc64
relocating kcrctabs when CONFIG_RELOCATABLE=y")
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-03 02:54:06 -07:00
|
|
|
#define __CRC_SYMBOL(sym, sec) \
|
|
|
|
|
asm(" .section \"___kcrctab" sec "+" #sym "\", \"a\" \n" \
|
2018-05-09 01:23:49 -06:00
|
|
|
" .weak __crc_" #sym " \n" \
|
|
|
|
|
" .long __crc_" #sym " \n" \
|
modversions: treat symbol CRCs as 32 bit quantities
The modversion symbol CRCs are emitted as ELF symbols, which allows us
to easily populate the kcrctab sections by relying on the linker to
associate each kcrctab slot with the correct value.
This has a couple of downsides:
- Given that the CRCs are treated as memory addresses, we waste 4 bytes
for each CRC on 64 bit architectures,
- On architectures that support runtime relocation, a R_<arch>_RELATIVE
relocation entry is emitted for each CRC value, which identifies it
as a quantity that requires fixing up based on the actual runtime
load offset of the kernel. This results in corrupted CRCs unless we
explicitly undo the fixup (and this is currently being handled in the
core module code)
- Such runtime relocation entries take up 24 bytes of __init space
each, resulting in a x8 overhead in [uncompressed] kernel size for
CRCs.
Switching to explicit 32 bit values on 64 bit architectures fixes most
of these issues, given that 32 bit values are not treated as quantities
that require fixing up based on the actual runtime load offset. Note
that on some ELF64 architectures [such as PPC64], these 32-bit values
are still emitted as [absolute] runtime relocatable quantities, even if
the value resolves to a build time constant. Since relative relocations
are always resolved at build time, this patch enables MODULE_REL_CRCS on
powerpc when CONFIG_RELOCATABLE=y, which turns the absolute CRC
references into relative references into .rodata where the actual CRC
value is stored.
So redefine all CRC fields and variables as u32, and redefine the
__CRC_SYMBOL() macro for 64 bit builds to emit the CRC reference using
inline assembler (which is necessary since 64-bit C code cannot use
32-bit types to hold memory addresses, even if they are ultimately
resolved using values that do not exceed 0xffffffff). To avoid
potential problems with legacy 32-bit architectures using legacy
toolchains, the equivalent C definition of the kcrctab entry is retained
for 32-bit architectures.
Note that this mostly reverts commit d4703aefdbc8 ("module: handle ppc64
relocating kcrctabs when CONFIG_RELOCATABLE=y")
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-03 02:54:06 -07:00
|
|
|
" .previous \n");
|
|
|
|
|
#endif
|
|
|
|
|
#else
|
2011-05-23 12:11:39 -06:00
|
|
|
#define __CRC_SYMBOL(sym, sec)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* For every exported symbol, place a struct in the __ksymtab section */
|
kbuild: allow archs to select link dead code/data elimination
Introduce LD_DEAD_CODE_DATA_ELIMINATION option for architectures to
select to build with -ffunction-sections, -fdata-sections, and link
with --gc-sections. It requires some work (documented) to ensure all
unreferenced entrypoints are live, and requires toolchain and build
verification, so it is made a per-arch option for now.
On a random powerpc64le build, this yelds a significant size saving,
it boots and runs fine, but there is a lot I haven't tested as yet, so
these savings may be reduced if there are bugs in the link.
text data bss dec filename
11169741 1180744 1923176 14273661 vmlinux
10445269 1004127 1919707 13369103 vmlinux.dce
~700K text, ~170K data, 6% removed from kernel image size.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 06:29:20 -06:00
|
|
|
#define ___EXPORT_SYMBOL(sym, sec) \
|
|
|
|
|
extern typeof(sym) sym; \
|
|
|
|
|
__CRC_SYMBOL(sym, sec) \
|
|
|
|
|
static const char __kstrtab_##sym[] \
|
|
|
|
|
__attribute__((section("__ksymtab_strings"), aligned(1))) \
|
2018-05-09 01:23:49 -06:00
|
|
|
= #sym; \
|
kbuild: allow archs to select link dead code/data elimination
Introduce LD_DEAD_CODE_DATA_ELIMINATION option for architectures to
select to build with -ffunction-sections, -fdata-sections, and link
with --gc-sections. It requires some work (documented) to ensure all
unreferenced entrypoints are live, and requires toolchain and build
verification, so it is made a per-arch option for now.
On a random powerpc64le build, this yelds a significant size saving,
it boots and runs fine, but there is a lot I haven't tested as yet, so
these savings may be reduced if there are bugs in the link.
text data bss dec filename
11169741 1180744 1923176 14273661 vmlinux
10445269 1004127 1919707 13369103 vmlinux.dce
~700K text, ~170K data, 6% removed from kernel image size.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 06:29:20 -06:00
|
|
|
static const struct kernel_symbol __ksymtab_##sym \
|
|
|
|
|
__used \
|
|
|
|
|
__attribute__((section("___ksymtab" sec "+" #sym), used)) \
|
2011-05-23 12:11:39 -06:00
|
|
|
= { (unsigned long)&sym, __kstrtab_##sym }
|
|
|
|
|
|
2018-08-21 22:56:04 -06:00
|
|
|
#if defined(__DISABLE_EXPORTS)
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Allow symbol exports to be disabled completely so that C code may
|
|
|
|
|
* be reused in other execution contexts such as the UEFI stub or the
|
|
|
|
|
* decompressor.
|
|
|
|
|
*/
|
|
|
|
|
#define __EXPORT_SYMBOL(sym, sec)
|
|
|
|
|
|
|
|
|
|
#elif defined(__KSYM_DEPS__)
|
kbuild: add fine grained build dependencies for exported symbols
Like with kconfig options, we now have the ability to compile in and
out individual EXPORT_SYMBOL() declarations based on the content of
include/generated/autoksyms.h. However we don't want the entire
world to be rebuilt whenever that file is touched.
Let's apply the same build dependency trick used for CONFIG_* symbols
where the time stamp of empty files whose paths matching those symbols
is used to trigger fine grained rebuilds. In our case the key is the
symbol name passed to EXPORT_SYMBOL().
However, unlike config options, we cannot just use fixdep to parse
the source code for EXPORT_SYMBOL(ksym) because several variants exist
and parsing them all in a separate tool, and keeping it in synch, is
not trivially maintainable. Furthermore, there are variants such as
EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
that are instanciated via a macro for which we can't easily determine
the actual exported symbol name(s) short of actually running the
preprocessor on them.
Storing the symbol name string in a special ELF section doesn't work
for targets that output assembly or preprocessed source.
So the best way is really to leverage the preprocessor by having it
output actual symbol names anchored by a special sequence that can be
easily filtered out. Then the list of symbols is simply fed to fixdep
to be merged with the other dependencies.
That implies the preprocessor is executed twice for each source file.
A previous attempt relied on a warning pragma for each EXPORT_SYMBOL()
instance that was filtered apart from stderr by the build system with
a sed script during the actual compilation pass. Unfortunately the
preprocessor/compiler diagnostic output isn't stable between versions
and this solution, although more efficient, was deemed too fragile.
Because of the lowercasing performed by fixdep, there might be name
collisions triggering spurious rebuilds for similar symbols. But this
shouldn't be a big issue in practice. (This is the case for CONFIG_*
symbols and I didn't want to be different here, whatever the original
reason for doing so.)
To avoid needless build overhead, the exported symbol name gathering is
performed only when CONFIG_TRIM_UNUSED_KSYMS is selected.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-22 11:41:57 -07:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* For fine grained build dependencies, we want to tell the build system
|
|
|
|
|
* about each possible exported symbol even if they're not actually exported.
|
|
|
|
|
* We use a string pattern that is unlikely to be valid code that the build
|
|
|
|
|
* system filters out from the preprocessor output (see ksym_dep_filter
|
|
|
|
|
* in scripts/Kbuild.include).
|
|
|
|
|
*/
|
|
|
|
|
#define __EXPORT_SYMBOL(sym, sec) === __KSYM_##sym ===
|
|
|
|
|
|
|
|
|
|
#elif defined(CONFIG_TRIM_UNUSED_KSYMS)
|
2016-01-21 23:32:26 -07:00
|
|
|
|
|
|
|
|
#include <generated/autoksyms.h>
|
|
|
|
|
|
|
|
|
|
#define __EXPORT_SYMBOL(sym, sec) \
|
2016-06-13 23:58:55 -06:00
|
|
|
__cond_export_sym(sym, sec, __is_defined(__KSYM_##sym))
|
2016-01-21 23:32:26 -07:00
|
|
|
#define __cond_export_sym(sym, sec, conf) \
|
|
|
|
|
___cond_export_sym(sym, sec, conf)
|
|
|
|
|
#define ___cond_export_sym(sym, sec, enabled) \
|
|
|
|
|
__cond_export_sym_##enabled(sym, sec)
|
|
|
|
|
#define __cond_export_sym_1(sym, sec) ___EXPORT_SYMBOL(sym, sec)
|
|
|
|
|
#define __cond_export_sym_0(sym, sec) /* nothing */
|
|
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
#define __EXPORT_SYMBOL ___EXPORT_SYMBOL
|
|
|
|
|
#endif
|
|
|
|
|
|
2011-05-23 12:11:39 -06:00
|
|
|
#define EXPORT_SYMBOL(sym) \
|
|
|
|
|
__EXPORT_SYMBOL(sym, "")
|
|
|
|
|
|
|
|
|
|
#define EXPORT_SYMBOL_GPL(sym) \
|
|
|
|
|
__EXPORT_SYMBOL(sym, "_gpl")
|
|
|
|
|
|
|
|
|
|
#define EXPORT_SYMBOL_GPL_FUTURE(sym) \
|
|
|
|
|
__EXPORT_SYMBOL(sym, "_gpl_future")
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_UNUSED_SYMBOLS
|
|
|
|
|
#define EXPORT_UNUSED_SYMBOL(sym) __EXPORT_SYMBOL(sym, "_unused")
|
|
|
|
|
#define EXPORT_UNUSED_SYMBOL_GPL(sym) __EXPORT_SYMBOL(sym, "_unused_gpl")
|
|
|
|
|
#else
|
|
|
|
|
#define EXPORT_UNUSED_SYMBOL(sym)
|
|
|
|
|
#define EXPORT_UNUSED_SYMBOL_GPL(sym)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#endif /* __GENKSYMS__ */
|
|
|
|
|
|
|
|
|
|
#else /* !CONFIG_MODULES... */
|
|
|
|
|
|
|
|
|
|
#define EXPORT_SYMBOL(sym)
|
|
|
|
|
#define EXPORT_SYMBOL_GPL(sym)
|
|
|
|
|
#define EXPORT_SYMBOL_GPL_FUTURE(sym)
|
|
|
|
|
#define EXPORT_UNUSED_SYMBOL(sym)
|
|
|
|
|
#define EXPORT_UNUSED_SYMBOL_GPL(sym)
|
|
|
|
|
|
|
|
|
|
#endif /* CONFIG_MODULES */
|
2013-03-14 22:34:17 -06:00
|
|
|
#endif /* !__ASSEMBLY__ */
|
2011-05-23 12:11:39 -06:00
|
|
|
|
|
|
|
|
#endif /* _LINUX_EXPORT_H */
|