Re: [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linking

["Ard Biesheuvel" <ard.biesheuvel@linaro.org>]

On Thu, 5 Sep 2019 at 10:16, Leif Lindholm <leif.lindholm@linaro.org> wrote:
>
> On Thu, Sep 05, 2019 at 10:06:56AM -0700, Ard Biesheuvel wrote:
> > On Thu, 5 Sep 2019 at 08:55, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > >
> > > On Thu, Sep 05, 2019 at 07:25:39AM -0700, Ard Biesheuvel wrote:
> > > > > >  [BuildOptions]
> > > > > > -  GCC:*_*_*_DLINK_FLAGS = -shared -Wl,-Bsymbolic -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > > > > > +  GCC:*_*_*_DLINK_FLAGS = -Wl,-Bsymbolic,-pie,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > > > >
> > > > > We already merged a fix for AARCH64 though - could/should this be
> > > > > active on ARM only?
> > > > >
> > > > > A problem I have with this patch is that ArmVirtQemuKernel curently
> > > > > doesn't boot on my qemu (with/without kvm, built with GCC5 or CLANG38,
> > > > > with or without this patch):
> > > > > ProcessPciHost: Config[0x4010000000+0x10000000) Bus[0x0..0xFF]
> > > > > Io[0x0+0x10000)@0x3EFF0000 Mem32[0x10000000+0x2EFF0000)@0x0
> > > > > Mem64[0x8000000000+0x8000000000)@0x0
> > > > > MapGcdMmioSpace: failed to set memory space attributes for region
> > > > > [0x4010000000+0x10000000)
> > > > >
> > > > > ASSERT_EFI_ERROR (Status = Unsupported)
> > > > > ASSERT [PciHostBridgeDxe]
> > > > > /work/git/edk2/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(293):
> > > > > !EFI_ERROR (Status)
> > > > > qemu-system-arm: terminating on signal 15 from pid 4680 (killall)
> > > > >
> > > >
> > > > Does it work with -M virt,highmem=off ?
> > >
> > > Ah, yes - that works fine then, also with the patch.
> > >
> > > Well, with that, and your explanation in the other thread:
> > > Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
> >
> > Thanks. I am going to replace the last paragraph of the commit log with
> >
> >     Note that in this particular case, we are interested in PIE linking
> >     only (i.e., producing a .rela section containing dynamic relocations
> >     that the startup code can process directly), and not in position
> >     independent code generation, and by passing the -pie option to the
> >     linker directly using -Wl,-pie (and dropping -shared), we can coerce
> >     the GOLD linker into doing only the former rather than both when it
> >     performs its LTO code generation.
> >
> > and push (unless you have any objections)
>
> No objections.
>

Thanks

Pushed as 8a1305a11f3b..04d9d89b7dd4