Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
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
> > > >
> > > > wrote:
> > > > > On Wed, Jun 5, 2019 at 9:26 AM 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-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
signature.asc
Description: This is a digitally signed message part.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
Ard Biesheuvel wrote: > On Thu, 6 Jun 2019 at 09:50, Rolf Eike Beer 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 signature.asc Description: This is a digitally signed message part.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Thu, 6 Jun 2019 at 09:08, Greg KH wrote: > > On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote: > > On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers > > wrote: > > > > > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > > > 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? > > > > > > 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.
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
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 signature.asc Description: This is a digitally signed message part.
