Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Greg KH]

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

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Nick Desaulniers]

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

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Nick Desaulniers]

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

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[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.
> >
> > 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

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Greg KH]

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

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Nick Desaulniers]

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

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Ard Biesheuvel]

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.

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Greg KH]

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

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Rolf Eike Beer]

[-- 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 --]

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Rolf Eike Beer]

[-- 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 --]

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Rolf Eike Beer]

[-- 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 --]

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Ard Biesheuvel]

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.

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Ard Biesheuvel]

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.

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Ard Biesheuvel]

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.

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Rolf Eike Beer]

[-- 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 --]

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Ard Biesheuvel]

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.

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Greg KH]

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

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Nathan Chancellor]

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

Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')

[Rolf Eike Beer]

[-- 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 --]