| Message ID | 20180202162104.2300532-3-arnd@arndb.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 2 Feb 2018, Arnd Bergmann wrote: > crypto_it_tab and the other symbols like it are defined in > crypto/aes_generic.c and exported for loadable modules. When > building with LTO and CONFIG_TRIM_UNUSED_KSYMS, the exports > are eliminated, since kbuild fails to take the users in > the arch/x86/crypto/aes-i586-asm_32.S assembler file into > account. > > This adds an ugly workaround by adding a reference to each symbol > into aes_glue.c, which gets linked together with the assembler > file. > > We obviously want to fix the CONFIG_TRIM_UNUSED_KSYMS logic > to do the right thing here instead, but I couldn't come up > with a good fix, so I use this instead to get a clean build > for testing. Could you give me the .config you used for this? So far I can't reproduce, and guessing with LTO takes lots of time. > This fix only works most of the time, but I still ran into > some cases where combining an .S with a .c file did not > produce the correct .ko file, as the lto linker apparently > did not expect that kind of input. 'nm' on the file after > 'ld -r' showed only the contents of the assembler file, and > after the lto-ld stage, only the contents of the .c file > are there. 'ld -r' does not support mixed (LTO and non-LTO) objects. Nicolas -- 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 Fri, Feb 2, 2018 at 8:49 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > On Fri, 2 Feb 2018, Arnd Bergmann wrote: > >> crypto_it_tab and the other symbols like it are defined in >> crypto/aes_generic.c and exported for loadable modules. When >> building with LTO and CONFIG_TRIM_UNUSED_KSYMS, the exports >> are eliminated, since kbuild fails to take the users in >> the arch/x86/crypto/aes-i586-asm_32.S assembler file into >> account. >> >> This adds an ugly workaround by adding a reference to each symbol >> into aes_glue.c, which gets linked together with the assembler >> file. >> >> We obviously want to fix the CONFIG_TRIM_UNUSED_KSYMS logic >> to do the right thing here instead, but I couldn't come up >> with a good fix, so I use this instead to get a clean build >> for testing. > > Could you give me the .config you used for this? So far I can't > reproduce, and guessing with LTO takes lots of time. I've uploaded my randconfig file to https://pastebin.com/raw/iLk4sSpw >> This fix only works most of the time, but I still ran into >> some cases where combining an .S with a .c file did not >> produce the correct .ko file, as the lto linker apparently >> did not expect that kind of input. 'nm' on the file after >> 'ld -r' showed only the contents of the assembler file, and >> after the lto-ld stage, only the contents of the .c file >> are there. > > 'ld -r' does not support mixed (LTO and non-LTO) objects. Ok, that would explain it. I checked that CONFIG_THIN_ARCHIVES is set here, but I see clearly that the module is linked using x86_64-linux-ld -m elf_x86_64 -r -o arch/x86/crypto/aes-x86_64.o arch/x86/crypto/aes-x86_64-asm_64.o arch/x86/crypto/aes_glue.o ; scripts/mod/modpost arch/x86/crypto/aes-x86_64.o Arnd -- 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
diff --git a/arch/x86/crypto/aes_glue.c b/arch/x86/crypto/aes_glue.c index e26984f7ab8d..6da3e3c34a77 100644 --- a/arch/x86/crypto/aes_glue.c +++ b/arch/x86/crypto/aes_glue.c @@ -53,6 +53,11 @@ static struct crypto_alg aes_alg = { static int __init aes_init(void) { + /* ugly hack to force a link time dependency */ + if (&crypto_it_tab == &crypto_ft_tab || + &crypto_fl_tab == &crypto_il_tab) + return 0; + return crypto_register_alg(&aes_alg); }
crypto_it_tab and the other symbols like it are defined in crypto/aes_generic.c and exported for loadable modules. When building with LTO and CONFIG_TRIM_UNUSED_KSYMS, the exports are eliminated, since kbuild fails to take the users in the arch/x86/crypto/aes-i586-asm_32.S assembler file into account. This adds an ugly workaround by adding a reference to each symbol into aes_glue.c, which gets linked together with the assembler file. We obviously want to fix the CONFIG_TRIM_UNUSED_KSYMS logic to do the right thing here instead, but I couldn't come up with a good fix, so I use this instead to get a clean build for testing. This fix only works most of the time, but I still ran into some cases where combining an .S with a .c file did not produce the correct .ko file, as the lto linker apparently did not expect that kind of input. 'nm' on the file after 'ld -r' showed only the contents of the assembler file, and after the lto-ld stage, only the contents of the .c file are there. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- arch/x86/crypto/aes_glue.c | 5 +++++ 1 file changed, 5 insertions(+)