* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') [not found] <779905244.a0lJJiZRjM@devpool35> @ 2019-06-05 16:26 ` Greg KH 2019-06-05 17:27 ` Nick Desaulniers ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Greg KH @ 2019-06-05 16:26 UTC (permalink / raw) To: Rolf Eike Beer, Nick Desaulniers Cc: Ard Biesheuvel, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > I decided to dig out a toy project which uses a DragonBoard 410c. This has > been "running" with kernel 4.9, which I would keep this way for unrelated > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > buildable, which was good enough. > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > stub.stub.o): in function `handle_kernel_image': > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be used > when making a shared object; recompile with -fPIC > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > (.init.text+0xc): dangerous relocation: unsupported relocation > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' failed > -make[1]: *** [vmlinux] Error 1 > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > this commit fixes the build. > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. See > the attached .config for reference. > > If you have questions or patches just ping me. Does Linus's latest tree also fail for you (or 5.1)? Nick, do we need to add another fix that is in mainline for this to work properly? thanks, greg k-h ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-05 16:26 ` Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') Greg KH @ 2019-06-05 17:27 ` Nick Desaulniers 2019-06-05 17:50 ` Nick Desaulniers 2019-06-05 18:42 ` Ard Biesheuvel 2019-06-06 7:38 ` Rolf Eike Beer 2 siblings, 1 reply; 19+ messages in thread From: Nick Desaulniers @ 2019-06-05 17:27 UTC (permalink / raw) To: Greg KH Cc: Rolf Eike Beer, Ard Biesheuvel, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, # 3.4.x, Matthias Kaehlcke On Wed, Jun 5, 2019 at 9:26 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > been "running" with kernel 4.9, which I would keep this way for unrelated > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > buildable, which was good enough. > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > > stub.stub.o): in function `handle_kernel_image': > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be used > > when making a shared object; recompile with -fPIC > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > (.init.text+0xc): dangerous relocation: unsupported relocation > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' failed > > -make[1]: *** [vmlinux] Error 1 > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > > this commit fixes the build. > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. See > > the attached .config for reference. > > > > If you have questions or patches just ping me. > > Does Linus's latest tree also fail for you (or 5.1)? > > Nick, do we need to add another fix that is in mainline for this to work > properly? > > thanks, > > greg k-h Doesn't immediately ring any bells for me. +mka@ who helped test 91ee5b21ee026c49e4e7483de69b55b8b47042be. Nothing in that series (https://lore.kernel.org/lkml/20170818194947.19347-5-ard.biesheuvel@linaro.org/T/#u) is immediately obvious. Rolf, can you please email me your config so I can see if I can reproduce? Also, which version of GCC are you using, and binutils? (would be good to know if you hit this in mainline too, as if not maybe there's an existing fix to be backported to stable). -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-05 17:27 ` Nick Desaulniers @ 2019-06-05 17:50 ` Nick Desaulniers 2019-06-06 7:11 ` Rolf Eike Beer 0 siblings, 1 reply; 19+ messages in thread From: Nick Desaulniers @ 2019-06-05 17:50 UTC (permalink / raw) To: Greg KH Cc: Rolf Eike Beer, Ard Biesheuvel, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, # 3.4.x, Matthias Kaehlcke, clang-built-linux On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > On Wed, Jun 5, 2019 at 9:26 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > > been "running" with kernel 4.9, which I would keep this way for unrelated > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > buildable, which was good enough. > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > > > stub.stub.o): in function `handle_kernel_image': > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > > > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be used > > > when making a shared object; recompile with -fPIC > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' failed > > > -make[1]: *** [vmlinux] Error 1 > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > > > this commit fixes the build. > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. See > > > the attached .config for reference. > > > > > > If you have questions or patches just ping me. > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > Nick, do we need to add another fix that is in mainline for this to work > > properly? > > > > thanks, > > > > greg k-h > > Doesn't immediately ring any bells for me. Upstream commits: dd6846d77469 ("arm64: drop linker script hack to hide __efistub_ symbols") 1212f7a16af4 ("scripts/kallsyms: filter arm64's __efistub_ symbols") Look related to __efistub__ prefixes on symbols and aren't in stable 4.9 (maybe Rolf can try cherry picks of those). -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-05 17:50 ` Nick Desaulniers @ 2019-06-06 7:11 ` Rolf Eike Beer 2019-08-02 7:57 ` Greg KH 0 siblings, 1 reply; 19+ messages in thread From: Rolf Eike Beer @ 2019-06-06 7:11 UTC (permalink / raw) To: Nick Desaulniers Cc: Greg KH, Ard Biesheuvel, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable, Matthias Kaehlcke, clang-built-linux [-- Attachment #1: Type: text/plain, Size: 3194 bytes --] Nick Desaulniers wrote: > On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers > > <ndesaulniers@google.com> wrote: > > On Wed, Jun 5, 2019 at 9:26 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > I decided to dig out a toy project which uses a DragonBoard 410c. This > > > > has > > > > been "running" with kernel 4.9, which I would keep this way for > > > > unrelated > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > > buildable, which was good enough. > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function > > > > `handle_kernel_image': > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c: > > > > 63: > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > aarch64-unknown-linux-gnueabi-ld: > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not > > > > be used when making a shared object; recompile with -fPIC > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c: > > > > 63: > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > reverting > > > > this commit fixes the build. > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as > > > > 9.1.0. See > > > > the attached .config for reference. > > > > > > > > If you have questions or patches just ping me. > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > > > Nick, do we need to add another fix that is in mainline for this to work > > > properly? > > > > > > thanks, > > > > > > greg k-h > > > > Doesn't immediately ring any bells for me. > > Upstream commits: > dd6846d77469 ("arm64: drop linker script hack to hide __efistub_ symbols") > 1212f7a16af4 ("scripts/kallsyms: filter arm64's __efistub_ symbols") > > Look related to __efistub__ prefixes on symbols and aren't in stable > 4.9 (maybe Rolf can try cherry picks of those). I now have cherry-picked these commits: dd6846d77469 fdfb69a72522e97f9105a6d39a5be0a465951ed8 1212f7a16af4 56067812d5b0e737ac2063e94a50f76b810d6ca3 The 2 additional ones were needed as dependencies of the others. Nothing of this has helped. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 313 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-06 7:11 ` Rolf Eike Beer @ 2019-08-02 7:57 ` Greg KH 2019-08-02 8:09 ` Nathan Chancellor 0 siblings, 1 reply; 19+ messages in thread From: Greg KH @ 2019-08-02 7:57 UTC (permalink / raw) To: Rolf Eike Beer Cc: Nick Desaulniers, Ard Biesheuvel, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable, Matthias Kaehlcke, clang-built-linux On Thu, Jun 06, 2019 at 09:11:00AM +0200, Rolf Eike Beer wrote: > Nick Desaulniers wrote: > > On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers > > > > <ndesaulniers@google.com> wrote: > > > On Wed, Jun 5, 2019 at 9:26 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > > I decided to dig out a toy project which uses a DragonBoard 410c. This > > > > > has > > > > > been "running" with kernel 4.9, which I would keep this way for > > > > > unrelated > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > > > buildable, which was good enough. > > > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function > > > > > `handle_kernel_image': > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c: > > > > > 63: > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not > > > > > be used when making a shared object; recompile with -fPIC > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c: > > > > > 63: > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > > reverting > > > > > this commit fixes the build. > > > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as > > > > > 9.1.0. See > > > > > the attached .config for reference. > > > > > > > > > > If you have questions or patches just ping me. > > > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > > > > > Nick, do we need to add another fix that is in mainline for this to work > > > > properly? > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > Doesn't immediately ring any bells for me. > > > > Upstream commits: > > dd6846d77469 ("arm64: drop linker script hack to hide __efistub_ symbols") > > 1212f7a16af4 ("scripts/kallsyms: filter arm64's __efistub_ symbols") > > > > Look related to __efistub__ prefixes on symbols and aren't in stable > > 4.9 (maybe Rolf can try cherry picks of those). > > I now have cherry-picked these commits: > > dd6846d77469 > fdfb69a72522e97f9105a6d39a5be0a465951ed8 > 1212f7a16af4 > 56067812d5b0e737ac2063e94a50f76b810d6ca3 > > The 2 additional ones were needed as dependencies of the others. Nothing of > this has helped. Did this ever get resolved, or is it still an issue? thanks, greg k-h ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-08-02 7:57 ` Greg KH @ 2019-08-02 8:09 ` Nathan Chancellor 2019-08-02 8:16 ` Rolf Eike Beer 0 siblings, 1 reply; 19+ messages in thread From: Nathan Chancellor @ 2019-08-02 8:09 UTC (permalink / raw) To: Greg KH Cc: Rolf Eike Beer, Nick Desaulniers, Ard Biesheuvel, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable, Matthias Kaehlcke, clang-built-linux On Fri, Aug 02, 2019 at 09:57:45AM +0200, Greg KH wrote: > On Thu, Jun 06, 2019 at 09:11:00AM +0200, Rolf Eike Beer wrote: > > Nick Desaulniers wrote: > > > On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers > > > > > > <ndesaulniers@google.com> wrote: > > > > On Wed, Jun 5, 2019 at 9:26 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > > > I decided to dig out a toy project which uses a DragonBoard 410c. This > > > > > > has > > > > > > been "running" with kernel 4.9, which I would keep this way for > > > > > > unrelated > > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > > > > buildable, which was good enough. > > > > > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function > > > > > > `handle_kernel_image': > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c: > > > > > > 63: > > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not > > > > > > be used when making a shared object; recompile with -fPIC > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c: > > > > > > 63: > > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > > > reverting > > > > > > this commit fixes the build. > > > > > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as > > > > > > 9.1.0. See > > > > > > the attached .config for reference. > > > > > > > > > > > > If you have questions or patches just ping me. > > > > > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > > > > > > > Nick, do we need to add another fix that is in mainline for this to work > > > > > properly? > > > > > > > > > > thanks, > > > > > > > > > > greg k-h > > > > > > > > Doesn't immediately ring any bells for me. > > > > > > Upstream commits: > > > dd6846d77469 ("arm64: drop linker script hack to hide __efistub_ symbols") > > > 1212f7a16af4 ("scripts/kallsyms: filter arm64's __efistub_ symbols") > > > > > > Look related to __efistub__ prefixes on symbols and aren't in stable > > > 4.9 (maybe Rolf can try cherry picks of those). > > > > I now have cherry-picked these commits: > > > > dd6846d77469 > > fdfb69a72522e97f9105a6d39a5be0a465951ed8 > > 1212f7a16af4 > > 56067812d5b0e737ac2063e94a50f76b810d6ca3 > > > > The 2 additional ones were needed as dependencies of the others. Nothing of > > this has helped. > > Did this ever get resolved, or is it still an issue? > > thanks, > > greg k-h > This appears to have been resolved by commit 8fca3c364683 ("efi/libstub: Unify command line param parsing") in 4.9.181. I can build defconfig + CONFIG_RANDOMIZE_BASE without any issues. Cheers, Nathan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-08-02 8:09 ` Nathan Chancellor @ 2019-08-02 8:16 ` Rolf Eike Beer 0 siblings, 0 replies; 19+ messages in thread From: Rolf Eike Beer @ 2019-08-02 8:16 UTC (permalink / raw) To: Nathan Chancellor Cc: Greg KH, Nick Desaulniers, Ard Biesheuvel, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable, Matthias Kaehlcke, clang-built-linux [-- Attachment #1: Type: text/plain, Size: 3041 bytes --] Nathan Chancellor wrote: > On Fri, Aug 02, 2019 at 09:57:45AM +0200, Greg KH wrote: > > On Thu, Jun 06, 2019 at 09:11:00AM +0200, Rolf Eike Beer wrote: > > > Nick Desaulniers wrote: > > > > On Wed, Jun 5, 2019 at 10:27 AM Nick Desaulniers > > > > > > > > <ndesaulniers@google.com> wrote: > > > > > On Wed, Jun 5, 2019 at 9:26 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > > > > I decided to dig out a toy project which uses a DragonBoard > > > > > > > 410c. This > > > > > > > has > > > > > > > been "running" with kernel 4.9, which I would keep this way for > > > > > > > unrelated > > > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but > > > > > > > it was > > > > > > > buildable, which was good enough. > > > > > > > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly > > > > > > > fail: > > > > > > > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in > > > > > > > function > > > > > > > `handle_kernel_image': > > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-s > > > > > > > tub.c: > > > > > > > 63: > > > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): > > > > > > > relocation > > > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can > > > > > > > not > > > > > > > be used when making a shared object; recompile with -fPIC > > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-s > > > > > > > tub.c: > > > > > > > 63: > > > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target > > > > > > > 'vmlinux' > > > > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > > > > > > > This is caused by commit > > > > > > > 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > > > > reverting > > > > > > > this commit fixes the build. > > Did this ever get resolved, or is it still an issue? > > This appears to have been resolved by commit 8fca3c364683 ("efi/libstub: > Unify command line param parsing") in 4.9.181. I can build defconfig + > CONFIG_RANDOMIZE_BASE without any issues. I can confirm that 4.9.186 builds without issues with my original config. Thanks for paying attention. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 313 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-05 16:26 ` Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') Greg KH 2019-06-05 17:27 ` Nick Desaulniers @ 2019-06-05 18:42 ` Ard Biesheuvel 2019-06-05 19:26 ` Greg KH 2019-06-05 20:48 ` Nick Desaulniers 2019-06-06 7:38 ` Rolf Eike Beer 2 siblings, 2 replies; 19+ messages in thread From: Ard Biesheuvel @ 2019-06-05 18:42 UTC (permalink / raw) To: Greg KH Cc: Rolf Eike Beer, Nick Desaulniers, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable On Wed, 5 Jun 2019 at 18:26, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > been "running" with kernel 4.9, which I would keep this way for unrelated > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > buildable, which was good enough. > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > > stub.stub.o): in function `handle_kernel_image': > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be used > > when making a shared object; recompile with -fPIC > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > (.init.text+0xc): dangerous relocation: unsupported relocation > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' failed > > -make[1]: *** [vmlinux] Error 1 > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > > this commit fixes the build. > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. See > > the attached .config for reference. > > > > If you have questions or patches just ping me. > > Does Linus's latest tree also fail for you (or 5.1)? > > Nick, do we need to add another fix that is in mainline for this to work > properly? > For the record, this is an example of why I think backporting those clang enablement patches is a bad idea. We can't actually build those kernels with clang, can we? So what is the point? </grumpy> It would be helpful to get a relocation dump (objdump -r) of arm64-stub.o to figure out which symbol needs a 'hidden' annotation to prevent GCC from emitting it as a PIC reference requiring a GOT. Alternatively, we can just revert this patch from 4.9 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-05 18:42 ` Ard Biesheuvel @ 2019-06-05 19:26 ` Greg KH 2019-06-05 20:48 ` Nick Desaulniers 1 sibling, 0 replies; 19+ messages in thread From: Greg KH @ 2019-06-05 19:26 UTC (permalink / raw) To: Ard Biesheuvel Cc: Rolf Eike Beer, Nick Desaulniers, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable On Wed, Jun 05, 2019 at 08:42:32PM +0200, Ard Biesheuvel wrote: > On Wed, 5 Jun 2019 at 18:26, Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > > been "running" with kernel 4.9, which I would keep this way for unrelated > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > buildable, which was good enough. > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > > > stub.stub.o): in function `handle_kernel_image': > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > > > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be used > > > when making a shared object; recompile with -fPIC > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' failed > > > -make[1]: *** [vmlinux] Error 1 > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > > > this commit fixes the build. > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. See > > > the attached .config for reference. > > > > > > If you have questions or patches just ping me. > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > Nick, do we need to add another fix that is in mainline for this to work > > properly? > > > > For the record, this is an example of why I think backporting those > clang enablement patches is a bad idea. We can't actually build those > kernels with clang, can we? So what is the point? </grumpy> Yes "we" can. I do. Why can't you? And lots of devices rely on clang support for their kernels, as much as I would like to ignore them, I can't :( thanks, greg k-h ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-05 18:42 ` Ard Biesheuvel 2019-06-05 19:26 ` Greg KH @ 2019-06-05 20:48 ` Nick Desaulniers 2019-06-06 6:55 ` Ard Biesheuvel 1 sibling, 1 reply; 19+ messages in thread From: Nick Desaulniers @ 2019-06-05 20:48 UTC (permalink / raw) To: Ard Biesheuvel Cc: Greg KH, Rolf Eike Beer, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable, clang-built-linux On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > For the record, this is an example of why I think backporting those > clang enablement patches is a bad idea. There's always a risk involved with backports of any kind; more CI coverage can help us mitigate some of these risks in an automated fashion before we get user reports like this. I meet with the KernelCI folks weekly, so I'll double check on the coverage of the stable tree's branches. The 0day folks are also very responsive and I've spoken with them a few times, so I'll try to get to the bottom of why this wasn't reported by either of those. Also, these patches help keep Android, CrOS, and Google internal production kernels closer to their upstream sources. > We can't actually build those > kernels with clang, can we? So what is the point? </grumpy> Here's last night's build: https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 Also, Android and CrOS have shipped X million devices w/ 4.9 kernels built with Clang. I think this number will grow at least one order of magnitude imminently. > Alternatively, we can just revert this patch from 4.9 That would break at least the above devices next time Android and CrOS pulled from stable. > It would be helpful to get a relocation dump (objdump -r) of > arm64-stub.o to figure out which symbol needs a 'hidden' annotation to > prevent GCC from emitting it as a PIC reference requiring a GOT. Sounds like the best way forward, as well as having more info on which config/toolchain reliably reproduces the issue. -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-05 20:48 ` Nick Desaulniers @ 2019-06-06 6:55 ` Ard Biesheuvel 2019-06-06 7:08 ` Greg KH 0 siblings, 1 reply; 19+ messages in thread From: Ard Biesheuvel @ 2019-06-06 6:55 UTC (permalink / raw) To: Nick Desaulniers Cc: Greg KH, Rolf Eike Beer, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable, clang-built-linux On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers <ndesaulniers@google.com> wrote: > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > <ard.biesheuvel@linaro.org> wrote: > > For the record, this is an example of why I think backporting those > > clang enablement patches is a bad idea. > > There's always a risk involved with backports of any kind; more CI > coverage can help us mitigate some of these risks in an automated > fashion before we get user reports like this. I meet with the > KernelCI folks weekly, so I'll double check on the coverage of the > stable tree's branches. The 0day folks are also very responsive and > I've spoken with them a few times, so I'll try to get to the bottom of > why this wasn't reported by either of those. > > Also, these patches help keep Android, CrOS, and Google internal > production kernels closer to their upstream sources. > > > We can't actually build those > > kernels with clang, can we? So what is the point? </grumpy> > > Here's last night's build: > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > If you are saying that plain upstream 4.9-stable defconfig can be built with Clang, then I am pleasantly surprised. > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > built with Clang. I think this number will grow at least one order of > magnitude imminently. > I know that (since you keep reminding me :-)), but obviously, Google does not care about changes that regress GCC support. > > Alternatively, we can just revert this patch from 4.9 > > That would break at least the above devices next time Android and CrOS > pulled from stable. > > > It would be helpful to get a relocation dump (objdump -r) of > > arm64-stub.o to figure out which symbol needs a 'hidden' annotation to > > prevent GCC from emitting it as a PIC reference requiring a GOT. > > Sounds like the best way forward, as well as having more info on which > config/toolchain reliably reproduces the issue. Let me know once you can reproduce it, I will have a look as well. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-06 6:55 ` Ard Biesheuvel @ 2019-06-06 7:08 ` Greg KH 2019-06-06 8:58 ` Ard Biesheuvel 0 siblings, 1 reply; 19+ messages in thread From: Greg KH @ 2019-06-06 7:08 UTC (permalink / raw) To: Ard Biesheuvel Cc: Nick Desaulniers, Rolf Eike Beer, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable, clang-built-linux On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote: > On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers <ndesaulniers@google.com> wrote: > > > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > > <ard.biesheuvel@linaro.org> wrote: > > > For the record, this is an example of why I think backporting those > > > clang enablement patches is a bad idea. > > > > There's always a risk involved with backports of any kind; more CI > > coverage can help us mitigate some of these risks in an automated > > fashion before we get user reports like this. I meet with the > > KernelCI folks weekly, so I'll double check on the coverage of the > > stable tree's branches. The 0day folks are also very responsive and > > I've spoken with them a few times, so I'll try to get to the bottom of > > why this wasn't reported by either of those. > > > > Also, these patches help keep Android, CrOS, and Google internal > > production kernels closer to their upstream sources. > > > > > We can't actually build those > > > kernels with clang, can we? So what is the point? </grumpy> > > > > Here's last night's build: > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > > > > If you are saying that plain upstream 4.9-stable defconfig can be > built with Clang, then I am pleasantly surprised. I know some specific configs can, there's no rule that I know of that 'defconfig' support is required. But then again, it might also work, try it and see :) > > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > > built with Clang. I think this number will grow at least one order of > > magnitude imminently. > > > > I know that (since you keep reminding me :-)), but obviously, Google > does not care about changes that regress GCC support. What are you talking about? Bugs happen all the time, what specifically did "Google" do to break gcc support? If you are referring to this patch, and it is a regression, of course I will revert it. But note that gcc and 4.9 works just fine for all of the other users right now, remember we do do a lot of testing of these releases. thanks, greg k-h ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-06 7:08 ` Greg KH @ 2019-06-06 8:58 ` Ard Biesheuvel 2019-06-06 9:34 ` Ard Biesheuvel 0 siblings, 1 reply; 19+ messages in thread From: Ard Biesheuvel @ 2019-06-06 8:58 UTC (permalink / raw) To: Greg KH Cc: Nick Desaulniers, Rolf Eike Beer, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable, clang-built-linux On Thu, 6 Jun 2019 at 09:08, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote: > > On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers <ndesaulniers@google.com> wrote: > > > > > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > > > <ard.biesheuvel@linaro.org> wrote: > > > > For the record, this is an example of why I think backporting those > > > > clang enablement patches is a bad idea. > > > > > > There's always a risk involved with backports of any kind; more CI > > > coverage can help us mitigate some of these risks in an automated > > > fashion before we get user reports like this. I meet with the > > > KernelCI folks weekly, so I'll double check on the coverage of the > > > stable tree's branches. The 0day folks are also very responsive and > > > I've spoken with them a few times, so I'll try to get to the bottom of > > > why this wasn't reported by either of those. > > > > > > Also, these patches help keep Android, CrOS, and Google internal > > > production kernels closer to their upstream sources. > > > > > > > We can't actually build those > > > > kernels with clang, can we? So what is the point? </grumpy> > > > > > > Here's last night's build: > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > > > > > > > If you are saying that plain upstream 4.9-stable defconfig can be > > built with Clang, then I am pleasantly surprised. > > I know some specific configs can, there's no rule that I know of that > 'defconfig' support is required. But then again, it might also work, > try it and see :) > Well, it is the rule that the arm64 maintainers use. > > > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > > > built with Clang. I think this number will grow at least one order of > > > magnitude imminently. > > > > > > > I know that (since you keep reminding me :-)), but obviously, Google > > does not care about changes that regress GCC support. > > What are you talking about? Bugs happen all the time, what specifically > did "Google" do to break gcc support? If you are referring to this > patch, and it is a regression, of course I will revert it. But note > that gcc and 4.9 works just fine for all of the other users right now, > remember we do do a lot of testing of these releases. > Don't get me wrong: I am not blaming Google for this. But having strict Documented/ stable-rules, violating them by backporting patches that are clearly not bug fixes, and *then* saying 'bugs happen all the time' makes no sense to me at all. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-06 8:58 ` Ard Biesheuvel @ 2019-06-06 9:34 ` Ard Biesheuvel 0 siblings, 0 replies; 19+ messages in thread From: Ard Biesheuvel @ 2019-06-06 9:34 UTC (permalink / raw) To: Greg KH Cc: Nick Desaulniers, Rolf Eike Beer, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable, clang-built-linux On Thu, 6 Jun 2019 at 10:58, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > On Thu, 6 Jun 2019 at 09:08, Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote: > > > On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers <ndesaulniers@google.com> wrote: > > > > > > > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > > > > <ard.biesheuvel@linaro.org> wrote: > > > > > For the record, this is an example of why I think backporting those > > > > > clang enablement patches is a bad idea. > > > > > > > > There's always a risk involved with backports of any kind; more CI > > > > coverage can help us mitigate some of these risks in an automated > > > > fashion before we get user reports like this. I meet with the > > > > KernelCI folks weekly, so I'll double check on the coverage of the > > > > stable tree's branches. The 0day folks are also very responsive and > > > > I've spoken with them a few times, so I'll try to get to the bottom of > > > > why this wasn't reported by either of those. > > > > > > > > Also, these patches help keep Android, CrOS, and Google internal > > > > production kernels closer to their upstream sources. > > > > > > > > > We can't actually build those > > > > > kernels with clang, can we? So what is the point? </grumpy> > > > > > > > > Here's last night's build: > > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > > > > > > > > > > If you are saying that plain upstream 4.9-stable defconfig can be > > > built with Clang, then I am pleasantly surprised. > > > > I know some specific configs can, there's no rule that I know of that > > 'defconfig' support is required. But then again, it might also work, > > try it and see :) > > > > Well, it is the rule that the arm64 maintainers use. > > > > > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > > > > built with Clang. I think this number will grow at least one order of > > > > magnitude imminently. > > > > > > > > > > I know that (since you keep reminding me :-)), but obviously, Google > > > does not care about changes that regress GCC support. > > > > What are you talking about? Bugs happen all the time, what specifically > > did "Google" do to break gcc support? If you are referring to this > > patch, and it is a regression, of course I will revert it. But note > > that gcc and 4.9 works just fine for all of the other users right now, > > remember we do do a lot of testing of these releases. > > > > Don't get me wrong: I am not blaming Google for this. But having > strict Documented/ stable-rules, violating them by backporting patches > that are clearly not bug fixes, and *then* saying 'bugs happen all the > time' makes no sense to me at all. BTW I hit the same issue immediately building 4.9.180 defconfig + CONFIG_RANDOMIZE_BASE=y, using my distro GCC (6.3.0), so I'd say the testing coverage is not sufficient. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-05 16:26 ` Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') Greg KH 2019-06-05 17:27 ` Nick Desaulniers 2019-06-05 18:42 ` Ard Biesheuvel @ 2019-06-06 7:38 ` Rolf Eike Beer 2019-06-06 7:50 ` Rolf Eike Beer 2 siblings, 1 reply; 19+ messages in thread From: Rolf Eike Beer @ 2019-06-06 7:38 UTC (permalink / raw) To: Greg KH Cc: Nick Desaulniers, Ard Biesheuvel, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable [-- Attachment #1: Type: text/plain, Size: 2146 bytes --] Greg KH wrote: > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > been "running" with kernel 4.9, which I would keep this way for unrelated > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > buildable, which was good enough. > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > aarch64-unknown-linux-gnueabi-ld: > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function > > `handle_kernel_image': > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > aarch64-unknown-linux-gnueabi-ld: > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be > > used when making a shared object; recompile with -fPIC > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > (.init.text+0xc): dangerous relocation: unsupported relocation > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > failed -make[1]: *** [vmlinux] Error 1 > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > > this commit fixes the build. > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. > > See > > the attached .config for reference. > > > > If you have questions or patches just ping me. > > Does Linus's latest tree also fail for you (or 5.1)? 5.1.7 with the same config as before and "make olddefconfig" builds for me. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 313 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-06 7:38 ` Rolf Eike Beer @ 2019-06-06 7:50 ` Rolf Eike Beer 2019-06-06 9:01 ` Ard Biesheuvel 0 siblings, 1 reply; 19+ messages in thread From: Rolf Eike Beer @ 2019-06-06 7:50 UTC (permalink / raw) To: Greg KH Cc: Nick Desaulniers, Ard Biesheuvel, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable [-- Attachment #1: Type: text/plain, Size: 2385 bytes --] Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > Greg KH wrote: > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > I decided to dig out a toy project which uses a DragonBoard 410c. This > > > has > > > been "running" with kernel 4.9, which I would keep this way for > > > unrelated > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > buildable, which was good enough. > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function > > > `handle_kernel_image': > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63 > > > : > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > aarch64-unknown-linux-gnueabi-ld: > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be > > > used when making a shared object; recompile with -fPIC > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63 > > > : > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > reverting > > > this commit fixes the build. > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. > > > See > > > the attached .config for reference. > > > > > > If you have questions or patches just ping me. > > > > Does Linus's latest tree also fail for you (or 5.1)? > > 5.1.7 with the same config as before and "make olddefconfig" builds for me. Just for the fun of it: both 4.19 and 4.19.48 also work. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 313 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-06 7:50 ` Rolf Eike Beer @ 2019-06-06 9:01 ` Ard Biesheuvel 2019-06-06 9:40 ` Rolf Eike Beer 0 siblings, 1 reply; 19+ messages in thread From: Ard Biesheuvel @ 2019-06-06 9:01 UTC (permalink / raw) To: Rolf Eike Beer Cc: Greg KH, Nick Desaulniers, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable On Thu, 6 Jun 2019 at 09:50, Rolf Eike Beer <eb@emlix.com> wrote: > > Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > > Greg KH wrote: > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > I decided to dig out a toy project which uses a DragonBoard 410c. This > > > > has > > > > been "running" with kernel 4.9, which I would keep this way for > > > > unrelated > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > > > buildable, which was good enough. > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in function > > > > `handle_kernel_image': > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63 > > > > : > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > aarch64-unknown-linux-gnueabi-ld: > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be > > > > used when making a shared object; recompile with -fPIC > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63 > > > > : > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > reverting > > > > this commit fixes the build. > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. > > > > See > > > > the attached .config for reference. > > > > > > > > If you have questions or patches just ping me. > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > 5.1.7 with the same config as before and "make olddefconfig" builds for me. > > Just for the fun of it: both 4.19 and 4.19.48 also work. > Thanks Rolf Could you please check whether patch 60f38de7a8d4e816100ceafd1b382df52527bd50 applies cleanly, and whether it fixes the problem? Thanks. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-06 9:01 ` Ard Biesheuvel @ 2019-06-06 9:40 ` Rolf Eike Beer 2019-06-06 9:54 ` Ard Biesheuvel 0 siblings, 1 reply; 19+ messages in thread From: Rolf Eike Beer @ 2019-06-06 9:40 UTC (permalink / raw) To: Ard Biesheuvel Cc: Greg KH, Nick Desaulniers, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable [-- Attachment #1: Type: text/plain, Size: 3031 bytes --] Ard Biesheuvel wrote: > On Thu, 6 Jun 2019 at 09:50, Rolf Eike Beer <eb@emlix.com> wrote: > > Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > > > Greg KH wrote: > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > > I decided to dig out a toy project which uses a DragonBoard 410c. > > > > > This > > > > > has > > > > > been "running" with kernel 4.9, which I would keep this way for > > > > > unrelated > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it > > > > > was > > > > > buildable, which was good enough. > > > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in > > > > > function > > > > > `handle_kernel_image': > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > c:63 > > > > > > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not > > > > > be > > > > > used when making a shared object; recompile with -fPIC > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > c:63 > > > > > > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target > > > > > 'vmlinux' > > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca > > > > > from > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > > reverting > > > > > this commit fixes the build. > > > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as > > > > > 9.1.0. > > > > > See > > > > > the attached .config for reference. > > > > > > > > > > If you have questions or patches just ping me. > > > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > > > 5.1.7 with the same config as before and "make olddefconfig" builds for > > > me. > > > > Just for the fun of it: both 4.19 and 4.19.48 also work. > Could you please check whether patch > 60f38de7a8d4e816100ceafd1b382df52527bd50 applies cleanly, and whether > it fixes the problem? Thanks. The part in drivers/firmware/efi/libstub/arm-stub.c needs to be applied by hand, but afterwards things build fine. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 313 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') 2019-06-06 9:40 ` Rolf Eike Beer @ 2019-06-06 9:54 ` Ard Biesheuvel 0 siblings, 0 replies; 19+ messages in thread From: Ard Biesheuvel @ 2019-06-06 9:54 UTC (permalink / raw) To: Rolf Eike Beer Cc: Greg KH, Nick Desaulniers, Linus Torvalds, Matt Fleming, Peter Zijlstra, Thomas Gleixner, linux-efi, Linux Kernel Developers List, stable On Thu, 6 Jun 2019 at 11:40, Rolf Eike Beer <eb@emlix.com> wrote: > > Ard Biesheuvel wrote: > > On Thu, 6 Jun 2019 at 09:50, Rolf Eike Beer <eb@emlix.com> wrote: > > > Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > > > > Greg KH wrote: > > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > > > I decided to dig out a toy project which uses a DragonBoard 410c. > > > > > > This > > > > > > has > > > > > > been "running" with kernel 4.9, which I would keep this way for > > > > > > unrelated > > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it > > > > > > was > > > > > > buildable, which was good enough. > > > > > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in > > > > > > function > > > > > > `handle_kernel_image': > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > > c:63 > > > > > > > > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not > > > > > > be > > > > > > used when making a shared object; recompile with -fPIC > > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > > c:63 > > > > > > > > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target > > > > > > 'vmlinux' > > > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca > > > > > > from > > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > > > reverting > > > > > > this commit fixes the build. > > > > > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as > > > > > > 9.1.0. > > > > > > See > > > > > > the attached .config for reference. > > > > > > > > > > > > If you have questions or patches just ping me. > > > > > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > > > > > 5.1.7 with the same config as before and "make olddefconfig" builds for > > > > me. > > > > > > Just for the fun of it: both 4.19 and 4.19.48 also work. > > > Could you please check whether patch > > 60f38de7a8d4e816100ceafd1b382df52527bd50 applies cleanly, and whether > > it fixes the problem? Thanks. > > The part in drivers/firmware/efi/libstub/arm-stub.c needs to be applied by > hand, but afterwards things build fine. > Thanks. I'll send out a backport. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2019-08-02 8:25 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <779905244.a0lJJiZRjM@devpool35> 2019-06-05 16:26 ` Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') Greg KH 2019-06-05 17:27 ` Nick Desaulniers 2019-06-05 17:50 ` Nick Desaulniers 2019-06-06 7:11 ` Rolf Eike Beer 2019-08-02 7:57 ` Greg KH 2019-08-02 8:09 ` Nathan Chancellor 2019-08-02 8:16 ` Rolf Eike Beer 2019-06-05 18:42 ` Ard Biesheuvel 2019-06-05 19:26 ` Greg KH 2019-06-05 20:48 ` Nick Desaulniers 2019-06-06 6:55 ` Ard Biesheuvel 2019-06-06 7:08 ` Greg KH 2019-06-06 8:58 ` Ard Biesheuvel 2019-06-06 9:34 ` Ard Biesheuvel 2019-06-06 7:38 ` Rolf Eike Beer 2019-06-06 7:50 ` Rolf Eike Beer 2019-06-06 9:01 ` Ard Biesheuvel 2019-06-06 9:40 ` Rolf Eike Beer 2019-06-06 9:54 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).