| Submitter | Alan Jenkins |
|---|---|
| Date | 2009-11-03 10:06:16 |
| Message ID | <1257242782-10496-5-git-send-email-alan-jenkins@tuffmail.co.uk> |
| Download | mbox | patch |
| Permalink | /patch/57252/ |
| State | New |
| Headers | show |
Comments
On Tue, Nov 3, 2009 at 05:06, Alan Jenkins wrote: > The next commit will require the use of MODULE_SYMBOL_PREFIX in > .tmp_exports-asm.S. Currently it is mixed in with C structure > definitions in "asm/module.h". Move the definition of this arch option > into Kconfig, so it can be easily accessed by any code. > > This also lets modpost.c use the same definition. Previously modpost > relied on a hardcoded list of architectures in mk_elfconfig.c. this should also let us push VMLINUX_SYMBOL() out of arch/*/kernel/vmlinux.lds.S and into asm-generic/vmlinux.lds.h ... > A build test for blackfin, one of the two MODULE_SYMBOL_PREFIX archs, > showed the generated code was unchanged. vmlinux was identical save > for build ids, and an apparently randomized suffix on a single "__key" > symbol in the kallsyms data). when you get localized (static) namespace collisions, the linker automatically does that > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1171,6 +1171,17 @@ config MODULE_SRCVERSION_ALL > > endif # MODULES > > +config HAVE_SYMBOL_PREFIX > + bool > + help > + Some arch toolchains use a `_' prefix for all user symbols. > + This option will be taken into account when loading modules. > + > +config SYMBOL_PREFIX > + string > + default "_" if HAVE_SYMBOL_PREFIX > + default "" in practice, the symbol prefix is an underscore. but there is no technical limitation here -- the toolchain could use whatever prefix they wanted so if the Kconfig option was pushed to arch/*/Kconfig, we could drop HAVE_SYMBOL_PREFIX and let the arch declare the exact SYMBOL_PREFIX value itself -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mike Frysinger wrote: > On Tue, Nov 3, 2009 at 05:06, Alan Jenkins wrote: > >> The next commit will require the use of MODULE_SYMBOL_PREFIX in >> .tmp_exports-asm.S. Currently it is mixed in with C structure >> definitions in "asm/module.h". Move the definition of this arch option >> into Kconfig, so it can be easily accessed by any code. >> >> This also lets modpost.c use the same definition. Previously modpost >> relied on a hardcoded list of architectures in mk_elfconfig.c. >> > > this should also let us push VMLINUX_SYMBOL() out of > arch/*/kernel/vmlinux.lds.S and into asm-generic/vmlinux.lds.h ... > > >> A build test for blackfin, one of the two MODULE_SYMBOL_PREFIX archs, >> showed the generated code was unchanged. vmlinux was identical save >> for build ids, and an apparently randomized suffix on a single "__key" >> symbol in the kallsyms data). >> > > when you get localized (static) namespace collisions, the linker > automatically does that > > >> --- a/init/Kconfig >> +++ b/init/Kconfig >> @@ -1171,6 +1171,17 @@ config MODULE_SRCVERSION_ALL >> >> endif # MODULES >> >> +config HAVE_SYMBOL_PREFIX >> + bool >> + help >> + Some arch toolchains use a `_' prefix for all user symbols. >> + This option will be taken into account when loading modules. >> + >> +config SYMBOL_PREFIX >> + string >> + default "_" if HAVE_SYMBOL_PREFIX >> + default "" >> > > in practice, the symbol prefix is an underscore. but there is no > technical limitation here -- the toolchain could use whatever prefix > they wanted > > so if the Kconfig option was pushed to arch/*/Kconfig, we could drop > HAVE_SYMBOL_PREFIX and let the arch declare the exact SYMBOL_PREFIX > value itself > -mike > I don't think that's possible. #define VMLINUX_SYMBOL(_sym_) _##_sym_ I don't know any "unstringify" operation. So I can't convert a string value of CONFIG_SYMBOL_PREFIX to the unquoted underscore we neeed for this macro. The same applies for the SYM() macro I use. Currently it assumes the prefix is a single underscore: #ifdef HAVE_SYMBOL_PREFIX #define __SYM(sym) _##sym #else #define __SYM(sym) sym #endif If we positively want to keep the generality, I guess I should put MODULE_SYMBOL_PREFIX in a header file of it's own. The disadvantage is that it makes it inaccessible to host programs again, like modpost (which currently hardcodes the list of affected architectures in mk_elfconfig.c). Personally I favour "look, a small cleanup!" against "who knows what crazy things the next toolchain will do". Of course I'm open to being outvoted by experience :). Regards Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 3, 2009 at 07:16, Alan Jenkins wrote: > Mike Frysinger wrote: >> On Tue, Nov 3, 2009 at 05:06, Alan Jenkins wrote: >>> The next commit will require the use of MODULE_SYMBOL_PREFIX in >>> .tmp_exports-asm.S. Currently it is mixed in with C structure >>> definitions in "asm/module.h". Move the definition of this arch option >>> into Kconfig, so it can be easily accessed by any code. >>> >>> This also lets modpost.c use the same definition. Previously modpost >>> relied on a hardcoded list of architectures in mk_elfconfig.c. >> >> this should also let us push VMLINUX_SYMBOL() out of >> arch/*/kernel/vmlinux.lds.S and into asm-generic/vmlinux.lds.h ... > > I don't think that's possible. > > #define VMLINUX_SYMBOL(_sym_) _##_sym_ > > I don't know any "unstringify" operation. So I can't convert a string value > of CONFIG_SYMBOL_PREFIX to the unquoted underscore we neeed for this macro. > The same applies for the SYM() macro I use. let the build system do the unstringify operation. qstrip = $(strip $(subst ",,$(1))) CPPFLAGS_vmlinux.lds += -DVMLINUX_SYMBOL_PREFIX=$(call qstrip,CONFIG_SYMBOL_PREFIX) > If we positively want to keep the generality, I guess I should put > MODULE_SYMBOL_PREFIX in a header file of it's own. The disadvantage is that > it makes it inaccessible to host programs again, like modpost (which > currently hardcodes the list of affected architectures in mk_elfconfig.c). having it in the arch Kconfig removes any and all possible limitations, and it keeps the cruft out of the common init/Kconfig and in the arch-specific Kconfig, and avoids a dead symbol (HAVE_SYMBOL_PREFIX) -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 03, 2009 at 07:30:20AM -0500, Mike Frysinger wrote: > On Tue, Nov 3, 2009 at 07:16, Alan Jenkins wrote: > > Mike Frysinger wrote: > >> On Tue, Nov 3, 2009 at 05:06, Alan Jenkins wrote: > >>> The next commit will require the use of MODULE_SYMBOL_PREFIX in > >>> .tmp_exports-asm.S. ??Currently it is mixed in with C structure > >>> definitions in "asm/module.h". ??Move the definition of this arch option > >>> into Kconfig, so it can be easily accessed by any code. > >>> > >>> This also lets modpost.c use the same definition. ??Previously modpost > >>> relied on a hardcoded list of architectures in mk_elfconfig.c. > >> > >> this should also let us push VMLINUX_SYMBOL() out of > >> arch/*/kernel/vmlinux.lds.S and into asm-generic/vmlinux.lds.h ... > > > > I don't think that's possible. > > > > ?? #define VMLINUX_SYMBOL(_sym_) _##_sym_ > > > > I don't know any "unstringify" operation. ??So I can't convert a string value > > of CONFIG_SYMBOL_PREFIX to the unquoted underscore we neeed for this macro. > > ??The same applies for the SYM() macro I use. > > let the build system do the unstringify operation. > qstrip = $(strip $(subst ",,$(1))) > CPPFLAGS_vmlinux.lds += -DVMLINUX_SYMBOL_PREFIX=$(call > qstrip,CONFIG_SYMBOL_PREFIX) > > > If we positively want to keep the generality, I guess I should put > > MODULE_SYMBOL_PREFIX in a header file of it's own. ??The disadvantage is that > > it makes it inaccessible to host programs again, like modpost (which > > currently hardcodes the list of affected architectures in mk_elfconfig.c). > > having it in the arch Kconfig removes any and all possible > limitations, and it keeps the cruft out of the common init/Kconfig and > in the arch-specific Kconfig, and avoids a dead symbol > (HAVE_SYMBOL_PREFIX) Having it in the Kconfig also makes it a nuisance for platforms that can use -elf and -linux toolchains for the same tree for different platforms. It would be nice to have this supported in such a way that we can just set a flag from the Makefile and have a compiler test that determines whether it is necessary or not. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 3, 2009 at 08:29, Paul Mundt wrote: > On Tue, Nov 03, 2009 at 07:30:20AM -0500, Mike Frysinger wrote: >> On Tue, Nov 3, 2009 at 07:16, Alan Jenkins wrote: >> > Mike Frysinger wrote: >> >> On Tue, Nov 3, 2009 at 05:06, Alan Jenkins wrote: >> >>> The next commit will require the use of MODULE_SYMBOL_PREFIX in >> >>> .tmp_exports-asm.S. ??Currently it is mixed in with C structure >> >>> definitions in "asm/module.h". ??Move the definition of this arch option >> >>> into Kconfig, so it can be easily accessed by any code. >> >>> >> >>> This also lets modpost.c use the same definition. ??Previously modpost >> >>> relied on a hardcoded list of architectures in mk_elfconfig.c. >> >> >> >> this should also let us push VMLINUX_SYMBOL() out of >> >> arch/*/kernel/vmlinux.lds.S and into asm-generic/vmlinux.lds.h ... >> > >> > I don't think that's possible. >> > >> > ?? #define VMLINUX_SYMBOL(_sym_) _##_sym_ >> > >> > I don't know any "unstringify" operation. ??So I can't convert a string value >> > of CONFIG_SYMBOL_PREFIX to the unquoted underscore we neeed for this macro. >> > ??The same applies for the SYM() macro I use. >> >> let the build system do the unstringify operation. >> qstrip = $(strip $(subst ",,$(1))) >> CPPFLAGS_vmlinux.lds += -DVMLINUX_SYMBOL_PREFIX=$(call >> qstrip,CONFIG_SYMBOL_PREFIX) >> >> > If we positively want to keep the generality, I guess I should put >> > MODULE_SYMBOL_PREFIX in a header file of it's own. ??The disadvantage is that >> > it makes it inaccessible to host programs again, like modpost (which >> > currently hardcodes the list of affected architectures in mk_elfconfig.c). >> >> having it in the arch Kconfig removes any and all possible >> limitations, and it keeps the cruft out of the common init/Kconfig and >> in the arch-specific Kconfig, and avoids a dead symbol >> (HAVE_SYMBOL_PREFIX) > > Having it in the Kconfig also makes it a nuisance for platforms that can > use -elf and -linux toolchains for the same tree for different platforms. > It would be nice to have this supported in such a way that we can just > set a flag from the Makefile and have a compiler test that determines > whether it is necessary or not. what arch is this an issue for ? the only symbol prefixed arches are Blackfin and H8300, and they dont provide toolchains that omit the prefix. if anything, the common build code could easily do: ifeq ($(CONFIG_SYMBOL_PREFIX),) CFLAGS += $(call cc-option,-fno-leading-underscore) endif trying to enable symbol prefix support dynamically based on the toolchain is a bad idea and pretty fragile. the arch-specific assembly code would have to be all rewritten to wrap all C-visible symbols with a macro like VMLINUX_SYMBOL(). i say let anyone who actually has such a system and wants to do such a crazy ass thing put together a working arch first before we worry about it. the current code doesnt preclude dynamic hooking anyways (manually adding -DCONFIG_xxx to CPPFLAGS). -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 03, 2009 at 08:39:29AM -0500, Mike Frysinger wrote: > On Tue, Nov 3, 2009 at 08:29, Paul Mundt wrote: > > Having it in the Kconfig also makes it a nuisance for platforms that can > > use -elf and -linux toolchains for the same tree for different platforms. > > It would be nice to have this supported in such a way that we can just > > set a flag from the Makefile and have a compiler test that determines > > whether it is necessary or not. > > what arch is this an issue for ? the only symbol prefixed arches are > Blackfin and H8300, and they dont provide toolchains that omit the > prefix. > No, those are the only symbol prefixed platforms enabled in the kernel at present because neither one ships different toolchains. The symbol prefixing itself is more an artifact of a -elf target contrasted with a -linux one than anything "platform" specific. Thus, any nommu platform using a bare metal or -elf toolchain can easily be used for building the kernel if this can be supported in a clean way. As such, a config option is not useful. > trying to enable symbol prefix support dynamically based on the > toolchain is a bad idea and pretty fragile. the arch-specific > assembly code would have to be all rewritten to wrap all C-visible > symbols with a macro like VMLINUX_SYMBOL(). > There is nothing fragile about it, symbols are either prefixed or they aren't. The common case for things like the syscall table obiously have to be wrapped, but so what? C_SYMBOL_PREFIX() used to be the norm back in the day, so it obiously worked well enough for the common case. > i say let anyone who actually has such a system and wants to do such a > crazy ass thing put together a working arch first before we worry > about it. the current code doesnt preclude dynamic hooking anyways > (manually adding -DCONFIG_xxx to CPPFLAGS). You talk about fragile bad ideas and then throw out defining Kconfig variables from Makefiles? This simply has no place in the Kconfig space, as it is now and always has been a toolchain property, not an architectural/platform one. The other thing you seem to have ignored is that pretty much everyone has such a system, it's only crippled platforms like blackfin and h8300 that don't support toolchains without the prefix. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 3, 2009 at 08:46, Paul Mundt wrote: > On Tue, Nov 03, 2009 at 08:39:29AM -0500, Mike Frysinger wrote: >> On Tue, Nov 3, 2009 at 08:29, Paul Mundt wrote: >> > Having it in the Kconfig also makes it a nuisance for platforms that can >> > use -elf and -linux toolchains for the same tree for different platforms. >> > It would be nice to have this supported in such a way that we can just >> > set a flag from the Makefile and have a compiler test that determines >> > whether it is necessary or not. >> >> what arch is this an issue for ? the only symbol prefixed arches are >> Blackfin and H8300, and they dont provide toolchains that omit the >> prefix. > > No, those are the only symbol prefixed platforms enabled in the kernel at > present because neither one ships different toolchains. and most likely never will. the Blackfin symbol prefix is every where, userspace included. > The symbol prefixing itself is more an artifact of a -elf target > contrasted with a -linux one than anything "platform" specific. Thus, any > nommu platform using a bare metal or -elf toolchain can easily be used > for building the kernel if this can be supported in a clean way. As such, > a config option is not useful. which has no bearing on the Blackfin case as every toolchain target can currently be used to build the kernel >> trying to enable symbol prefix support dynamically based on the >> toolchain is a bad idea and pretty fragile. the arch-specific >> assembly code would have to be all rewritten to wrap all C-visible >> symbols with a macro like VMLINUX_SYMBOL(). > > There is nothing fragile about it, symbols are either prefixed or they > aren't. The common case for things like the syscall table obiously have > to be wrapped, but so what? C_SYMBOL_PREFIX() used to be the norm back in > the day, so it obiously worked well enough for the common case. it worked well when it was the *common* case as you said. when people rarely use it (which is what happens today), things constantly break because no one tests it, the usage is awkward, and it's an artifact that shouldnt exist in the first place. >> i say let anyone who actually has such a system and wants to do such a >> crazy ass thing put together a working arch first before we worry >> about it. the current code doesnt preclude dynamic hooking anyways >> (manually adding -DCONFIG_xxx to CPPFLAGS). > > You talk about fragile bad ideas and then throw out defining Kconfig > variables from Makefiles? This simply has no place in the Kconfig space, > as it is now and always has been a toolchain property, not an > architectural/platform one. my point was that it can easily be mixed. i personally could care less where the symbol is declared so long as it's declared just once. > The other thing you seem to have ignored is that pretty much everyone has > such a system, it's only crippled platforms like blackfin and h8300 that > don't support toolchains without the prefix. "cripple" is exactly the right word. why in the world do you want to cripple people that dont need it ? attempting to support busted toolchains by forcing even more symbol prefix crap throughout an arch makes no sense at all. use the -fno-leading-underscore gcc option if you want to re-use a non-standard symbol prefixed elf compiler to build an arch. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 03, 2009 at 08:58:49AM -0500, Mike Frysinger wrote: > On Tue, Nov 3, 2009 at 08:46, Paul Mundt wrote: > > The other thing you seem to have ignored is that pretty much everyone has > > such a system, it's only crippled platforms like blackfin and h8300 that > > don't support toolchains without the prefix. > > "cripple" is exactly the right word. why in the world do you want to > cripple people that dont need it ? attempting to support busted > toolchains by forcing even more symbol prefix crap throughout an arch > makes no sense at all. use the -fno-leading-underscore gcc option if > you want to re-use a non-standard symbol prefixed elf compiler to > build an arch. My main consideration is for some SH-2 compilers where only bare metal targets exist which could theoretically be used for the kernel, too. I've avoided tying them in precisely because there wasn't a very clean way to support the prefixed and non-prefixed case dynamically. On the other hand, in those cases I don't think anyone actually cares about the ABI, so having gcc not emit the prefix in the first place could be a valid alternative, I'll give that a try, as that would simplify things a fair bit. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig index 9a01d44..6c99419 100644 --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -26,6 +26,7 @@ config BLACKFIN select HAVE_KERNEL_BZIP2 select HAVE_KERNEL_LZMA select HAVE_OPROFILE + select HAVE_SYMBOL_PREFIX select ARCH_WANT_OPTIONAL_GPIOLIB config GENERIC_BUG diff --git a/arch/blackfin/include/asm/module.h b/arch/blackfin/include/asm/module.h index e3128df..81d8b90 100644 --- a/arch/blackfin/include/asm/module.h +++ b/arch/blackfin/include/asm/module.h @@ -1,8 +1,6 @@ #ifndef _ASM_BFIN_MODULE_H #define _ASM_BFIN_MODULE_H -#define MODULE_SYMBOL_PREFIX "_" - #define Elf_Shdr Elf32_Shdr #define Elf_Sym Elf32_Sym #define Elf_Ehdr Elf32_Ehdr diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig index 9420648..cc03bbf 100644 --- a/arch/h8300/Kconfig +++ b/arch/h8300/Kconfig @@ -9,6 +9,7 @@ config H8300 bool default y select HAVE_IDE + select HAVE_SYMBOL_PREFIX config MMU bool diff --git a/arch/h8300/include/asm/module.h b/arch/h8300/include/asm/module.h index de23231..8e46724 100644 --- a/arch/h8300/include/asm/module.h +++ b/arch/h8300/include/asm/module.h @@ -8,6 +8,4 @@ struct mod_arch_specific { }; #define Elf_Sym Elf32_Sym #define Elf_Ehdr Elf32_Ehdr -#define MODULE_SYMBOL_PREFIX "_" - #endif /* _ASM_H8/300_MODULE_H */ diff --git a/include/linux/mod_export.h b/include/linux/mod_export.h index 3d80057..56b817a 100644 --- a/include/linux/mod_export.h +++ b/include/linux/mod_export.h @@ -4,10 +4,8 @@ #include <linux/compiler.h> #include <asm/module.h> -/* some toolchains uses a `_' prefix for all user symbols */ -#ifndef MODULE_SYMBOL_PREFIX -#define MODULE_SYMBOL_PREFIX "" -#endif +/* Some toolchains use a `_' prefix for all user symbols. */ +#define MODULE_SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX struct kernel_symbol { unsigned long value; diff --git a/init/Kconfig b/init/Kconfig index c7bac39..fe43d6d 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1171,6 +1171,17 @@ config MODULE_SRCVERSION_ALL endif # MODULES +config HAVE_SYMBOL_PREFIX + bool + help + Some arch toolchains use a `_' prefix for all user symbols. + This option will be taken into account when loading modules. + +config SYMBOL_PREFIX + string + default "_" if HAVE_SYMBOL_PREFIX + default "" + config INIT_ALL_POSSIBLE bool help diff --git a/scripts/mod/Makefile b/scripts/mod/Makefile index 11d69c3..ff954f8 100644 --- a/scripts/mod/Makefile +++ b/scripts/mod/Makefile @@ -8,7 +8,7 @@ modpost-objs := modpost.o file2alias.o sumversion.o $(obj)/modpost.o $(obj)/file2alias.o $(obj)/sumversion.o: $(obj)/elfconfig.h quiet_cmd_elfconfig = MKELF $@ - cmd_elfconfig = $(obj)/mk_elfconfig $(ARCH) < $< > $@ + cmd_elfconfig = $(obj)/mk_elfconfig < $< > $@ $(obj)/elfconfig.h: $(obj)/empty.o $(obj)/mk_elfconfig FORCE $(call if_changed,elfconfig) diff --git a/scripts/mod/mk_elfconfig.c b/scripts/mod/mk_elfconfig.c index 6a96d47..639bca7 100644 --- a/scripts/mod/mk_elfconfig.c +++ b/scripts/mod/mk_elfconfig.c @@ -9,9 +9,6 @@ main(int argc, char **argv) unsigned char ei[EI_NIDENT]; union { short s; char c[2]; } endian_test; - if (argc != 2) { - fprintf(stderr, "Error: no arch\n"); - } if (fread(ei, 1, EI_NIDENT, stdin) != EI_NIDENT) { fprintf(stderr, "Error: input truncated\n"); return 1; @@ -55,12 +52,6 @@ main(int argc, char **argv) else exit(1); - if ((strcmp(argv[1], "h8300") == 0) - || (strcmp(argv[1], "blackfin") == 0)) - printf("#define MODULE_SYMBOL_PREFIX \"_\"\n"); - else - printf("#define MODULE_SYMBOL_PREFIX \"\"\n"); - return 0; } diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 801a16a..3867481 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -15,8 +15,12 @@ #include <stdio.h> #include <ctype.h> #include "modpost.h" +#include "../../include/linux/autoconf.h" #include "../../include/linux/license.h" +/* Some toolchains use a `_' prefix for all user symbols. */ +#define MODULE_SYMBOL_PREFIX CONFIG_SYMBOL_PREFIX + /* Are we using CONFIG_MODVERSIONS? */ int modversions = 0; /* Warn about undefined symbols? (do so if we have vmlinux) */
The next commit will require the use of MODULE_SYMBOL_PREFIX in .tmp_exports-asm.S. Currently it is mixed in with C structure definitions in "asm/module.h". Move the definition of this arch option into Kconfig, so it can be easily accessed by any code. This also lets modpost.c use the same definition. Previously modpost relied on a hardcoded list of architectures in mk_elfconfig.c. A build test for blackfin, one of the two MODULE_SYMBOL_PREFIX archs, showed the generated code was unchanged. vmlinux was identical save for build ids, and an apparently randomized suffix on a single "__key" symbol in the kallsyms data). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> --- arch/blackfin/Kconfig | 1 + arch/blackfin/include/asm/module.h | 2 -- arch/h8300/Kconfig | 1 + arch/h8300/include/asm/module.h | 2 -- include/linux/mod_export.h | 6 ++---- init/Kconfig | 11 +++++++++++ scripts/mod/Makefile | 2 +- scripts/mod/mk_elfconfig.c | 9 --------- scripts/mod/modpost.c | 4 ++++ 9 files changed, 20 insertions(+), 18 deletions(-)