Re: [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources

[Marcin Wojtas <mw@semihalf.com>]

Hi Ard,

2017-11-16 16:45 GMT+01:00 Ard Biesheuvel <ard.biesheuvel@linaro.org>:
> On 16 November 2017 at 15:31, Gao, Liming <liming.gao@intel.com> wrote:
>> Ard:
>>   Does this error only happen on ACPI table compiling? But, I see -no-pie is also in normal DLINK flag. Why is the driver not compiled failed?
>>
>
> The main difference is that the ACPI tables don't tolerate any padding
> at the start of the binary image. This is different for ELF binaries
> that are converted to PE/COFF, given that the entry point is exposed
> in the header, so the padding is just ignored. However, we should
> still try to omit those sections if we can.
>
>
>
>>> -----Original Message-----
>>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>>> Sent: Thursday, November 16, 2017 11:09 PM
>>> To: Marcin Wojtas <mw@semihalf.com>
>>> Cc: Gao, Liming <liming.gao@intel.com>; edk2-devel@lists.01.org; daniel.thompson@linaro.org; leif.lindholm@linaro.org
>>> Subject: Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources
>>>
>>> On 16 November 2017 at 15:07, Marcin Wojtas <mw@semihalf.com> wrote:
>>> > Hi Ard,
>>> >
>>> > 2017-11-16 15:48 GMT+01:00 Ard Biesheuvel <ard.biesheuvel@linaro.org>:
>>> >> On 16 November 2017 at 14:38, Marcin Wojtas <mw@semihalf.com> wrote:
>>> >>> Hi Ard,
>>> >>>
>>> >>> With both PIE disabling patches for AARCH64, when compiling ACPI tables with
>>> >>> gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
>>> >>> I get following errors:
>>> >>> [...]
>>> >>> aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
>>> >>> Do I understand correctly, that I should either revert those patches
>>> >>> or upgrade to the newer toolchain?
>>> >>>
>>> >>
>>> >> Ugh.
>>> >>
>>> >> I thought GCC 5 and later implemented -no-pie, but apparently not.
>>> >>
>>> >> Does this fix your build? I will need to check whether it fixes the
>>> >> original issue, but hopefully your toolchain doesn't choke on this:
>>> >>
>>> >> diff --git a/BaseTools/Conf/tools_def.template
>>> >> b/BaseTools/Conf/tools_def.template
>>> >> index aebd7d558633..111fe8da7773 100755
>>> >> --- a/BaseTools/Conf/tools_def.template
>>> >> +++ b/BaseTools/Conf/tools_def.template
>>> >> @@ -4496,10 +4496,10 @@ DEFINE GCC5_AARCH64_CC_FLAGS         =
>>> >> DEF(GCC49_AARCH64_CC_FLAGS)
>>> >>  DEFINE GCC5_AARCH64_CC_XIPFLAGS      = DEF(GCC49_AARCH64_CC_XIPFLAGS)
>>> >>  DEFINE GCC5_ARM_DLINK_FLAGS          = DEF(GCC49_ARM_DLINK_FLAGS) -no-pie
>>> >>  DEFINE GCC5_ARM_DLINK2_FLAGS         = DEF(GCC49_ARM_DLINK2_FLAGS) -Wno-error
>>> >> -DEFINE GCC5_AARCH64_DLINK_FLAGS      = DEF(GCC49_AARCH64_DLINK_FLAGS) -no-pie
>>> >> +DEFINE GCC5_AARCH64_DLINK_FLAGS      = DEF(GCC49_AARCH64_DLINK_FLAGS)
>>> >> -Wl,-no-pie
>>> >>  DEFINE GCC5_AARCH64_DLINK2_FLAGS     =
>>> >> DEF(GCC49_AARCH64_DLINK2_FLAGS) -Wno-error
>>> >>  DEFINE GCC5_ARM_ASLDLINK_FLAGS       = DEF(GCC49_ARM_ASLDLINK_FLAGS) -no-pie
>>> >> -DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
>>> >> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -no-pie
>>> >> +DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   =
>>> >> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -Wl,-no-pie
>>> >>
>>> >>  ####################################################################################
>>> >>  #
>>> >>
>>> >
>>> > Unfortunately no change, still:
>>> > aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie'
>>> > In order to make sure, I double checked twice cleaninig everything and
>>> > rebuilding from scratch.
>>> >
>>>
>>> Thanks, but it doesn't matter anyway: it doesn't fix the original
>>> issues on affected toolchains.
>>>
>>> It appears the only way we can deal with this is introducing GCC6 and
>>> move the workaround there.
>>>

Do you think it would be reasonable to revert:
3380a59 - BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources
1894a7c - BaseTools/tools_def AARCH64 ARM: disable PIE linking
on the EDK2 master branch, so that the users are not affected before
the actual workaround for problematic builds is moved to GCC6?

Best regards,
Marcin