Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
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.
Greetings,
Eike
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
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.or...) 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).
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).
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
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
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
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
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
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
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/11438843...
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.
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/11438843...
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.
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/11438843...
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
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/11438843...
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.
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/11438843...
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.
Am Mittwoch, 5. Juni 2019, 20:42:32 CEST schrieb Ard Biesheuvel:
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.
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
See attached file. This is with a few patches cherry-picked from upstream, none of them did help. Hope that doesn't make anything worse, at least the error message looks the same.
Eike
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
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
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.
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
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.
linux-stable-mirror@lists.linaro.org
-
Ard Biesheuvel -
Greg KH -
Nathan Chancellor -
Nick Desaulniers -
Rolf Eike Beer