Re: Relocation fixup during AARCH64 SEC PE-COFF generation?

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

On 13 September 2016 at 16:16, Achin Gupta <achin.gupta@arm.com> wrote:
> On Tue, Sep 13, 2016 at 03:43:41PM +0100, Ard Biesheuvel wrote:
>> On 13 September 2016 at 15:12, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> > On 13 September 2016 at 15:03, Achin Gupta <achin.gupta@arm.com> wrote:
>> >> Hi All,
>> >>
>> >> Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC module
>> >> executes directly from within the firmware volume. The FV would typically be
>> >> loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for SEC file
>> >> types converts a PE-COFF module into a stripped Terse executable as follows:
>> >>
>> >> [Rule.AARCH64.SEC]
>> >>   FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
>> >>     TE  TE    Align = Auto              $(INF_OUTPUT)/$(MODULE_NAME).efi
>> >>   }
>> >>
>> >> The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relocs" option
>> >> when the ELF image is generated. Since the SEC module is able to "XIP" from the
>> >> within FV, this means that the relocations have to be fixed up at link time
>> >> before the TE image is created.
>> >>
>> >
>> > Correct. GenFv relocates the image based on the runtime address of the
>> > firmware volume.
>> >
>> >> It seems to me that in GenFw.c, at least the static relocations are fixed up
>> >> when an ELF image is converted to PE-COFF. Can someone confirm if I am correct
>> >> in understanding that dynamic relocations will be left as is in the PE-COFF
>> >> image while static relocations will be fixed up?
>> >>
>> >
>> > We usually don't emit dynamic relocations, since we are not linking
>> > shared objects.
>>
>> ... or more specifically, all absolute static relocations are
>> converted into PE/COFF base relocations, all relative static
>> relocations are validated against the PE/COFF layout (which we keep
>> 1:1 identical with the ELF section layout), and all dynamic
>> relocations are ignored.
>
> Thanks Ard. I expect the relative static relocations to be fixed by the PE-COFF
> loader at runtime.
>

No. The PE/COFF loader only processes base relocations, which are
essentially pointers into the image where absolute addresses are
stored, and which need to have an offset applied based on the
difference between the link time base address and the load time base
address. Like in ELF, no relative dynamic relocations exist.

Only because of the ELF to PE/COFF conversion, we have to ensure that
any relative references are still valid after the conversion.

>> Note that this implies that proxy generating
>> static relocations are rejected, since --emit-relocs does not produce
>> any output for the proxies.
>
> You lost me here. What do you mean by "proxy generating static relocations"?
>

Basically, GOT based relocations that result in a GOT entry to be
emitted when linking a shared object. Since those relocations are
essentially instructions to the linker to emit such a GOT entry, the
absolute relocation itself which causes the GOT entry to hold the
correct value at runtime is not present in the object file, will hence
not be emitted by --emit-relocs, and so will not have a corresponding
PE/COFF base relocation emitted for it. This is the reason why we
currently cannot support such GOT based relocations.