From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 72E1F1A1E30 for ; Tue, 13 Sep 2016 09:04:09 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id 186so48962679itf.0 for ; Tue, 13 Sep 2016 09:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n4Dnd6EOUL/rBepr/QX9IBRO4hQf1QBbPx8TLjb+52Y=; b=CzzSsbTwETJaYgK7dwFW2E95t1APv0Kbkg2kzsNMcMh0sf5gFGxD/bojniyur2JxXZ GsFrwWjAANVWp1OEbf2vx/ucQQ4gOQoo31FQ7s8nFF6yVWYKnT19JK3A5+cPOIUKXz7E K1FnC9rwUjzAhwWxa4/8XRDrahEScJBfVhpvk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n4Dnd6EOUL/rBepr/QX9IBRO4hQf1QBbPx8TLjb+52Y=; b=MLlvDS3GfUmac7aDUloxK340pmt0paNj0KcgTz5NOGav5Qf+LlzX668nCI/5Rk6dD0 m4sJFcaV7dqopderUK3Yx8bZ7oRVChHdEE32B1QPikBbcxz9adyxTrUcThsBWIYRZB3/ cnVKae8FqmAOEWxv7VRVn4gEe6i7Adtk2zUcfE4nkzzTn7LNE4n0qwzRPpPOAGf3xu7W 4xshPKFhQooTOMLqqN6noYy+RHzEWnXNwc8IF+pMFFwf7RhIPtsY6OEa4NCSmUxWNjT3 Zu3NajFMWRxhc/fTSjyXEmuECOB6Xbdeguy2zE5oS3plRSqbOB9+apGbJLp/bqj2R4ZR S+bg== X-Gm-Message-State: AE9vXwN22/U1Ebg6jNORpkErrsIUMKNswDhJEzzDWEMNTVLsQ1+OOwL+8WCaTQsU4QJQlKeQUn5ET8PzF1ZTcKN1 X-Received: by 10.107.9.32 with SMTP id j32mr2564763ioi.153.1473782487128; Tue, 13 Sep 2016 09:01:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Tue, 13 Sep 2016 09:01:26 -0700 (PDT) In-Reply-To: <20160913155540.GF540@e102648.cambridge.arm.com> References: <20160913140236.GC540@e102648.cambridge.arm.com> <20160913151543.GE540@e102648.cambridge.arm.com> <20160913155540.GF540@e102648.cambridge.arm.com> From: Ard Biesheuvel Date: Tue, 13 Sep 2016 17:01:26 +0100 Message-ID: To: Achin Gupta Cc: edk2-devel-01 Subject: Re: Relocation fixup during AARCH64 SEC PE-COFF generation? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 16:04:09 -0000 Content-Type: text/plain; charset=UTF-8 On 13 September 2016 at 16:55, Achin Gupta wrote: > On Tue, Sep 13, 2016 at 04:25:32PM +0100, Ard Biesheuvel wrote: >> On 13 September 2016 at 16:16, Achin Gupta wrote: >> > On Tue, Sep 13, 2016 at 03:43:41PM +0100, Ard Biesheuvel wrote: >> >> On 13 September 2016 at 15:12, Ard Biesheuvel wrote: >> >> > On 13 September 2016 at 15:03, Achin Gupta 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. > > Obviously I am not well versed with the correct terminology :( > > I guess we are both talking about the base relocations done in > PeCoffLoaderRelocateImage() (MdePkg/Library/BasePeCoffLib/BasePeCoff.c) i.e. the > EFI_IMAGE_REL_BASED_* types defined in EfiImage.h? > Correct. >> >> >> 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. > > makes sense! Thanks for the clarification. > My pleasure, Ard.