From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 11ED01A1E0B for ; Tue, 13 Sep 2016 08:25:34 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id n143so42621060ita.1 for ; Tue, 13 Sep 2016 08:25:34 -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=5m+gRO6FHPLL3RRkITy5mRnT3KEtYu56epN5EOTXyUA=; b=i1ii8SyI1SsaJA2dsuRn3WRR5GOz5vpQLTfV3ZW3nj+7aOmF/t7rSUkLYlpnh22PLA po+nDNqYVFtw5zsH05FpjyCJExhN+LY8aaUqIreTCkhgN2j623hdQ17UJiWQGRbq9S6Q kBKD9FLlD4fiSYr6SrNotO55hBdCoOl8bBk3s= 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=5m+gRO6FHPLL3RRkITy5mRnT3KEtYu56epN5EOTXyUA=; b=HJjM+gXP7Ktd3SnLwBwkkKxmFf5o2k8yPWJhIjw4LiiXn9nvE9tqsD10bdnHkVeW9W F2/m1M9AAL8trYThCwhkbnUKI2v7nk5m1rDaNeuO610kcyrXtM2u2FPip5rpxxzozQ80 /yxN0eT+lZUbTD4S1NV3Fuzx3gTRFf/AGe8S5MXJs9QZumXZ7wMxEJQX4JNk72fJ8hSZ MP8N9blc5OInP13YX2o8snyHt0GAJqTKF0KHSexPoV//cHnNjNQluQUj2b/z7aDhIIT8 /bmetB3cSd39xn1vfzl53tRO46JwISSwvSp1MSSg4vO2ALp6UINc3AVQOCpYKsC3u56X RDMg== X-Gm-Message-State: AE9vXwMEDfUqpGxWS9ksQV+HDy6/gVUVwbkw7hKcUhGpuWPz/bLt/Q7cCpea83ui8Xw2CWLCwt2H3FsMHJENyCzg X-Received: by 10.107.9.32 with SMTP id j32mr2273330ioi.153.1473780333382; Tue, 13 Sep 2016 08:25:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Tue, 13 Sep 2016 08:25:32 -0700 (PDT) In-Reply-To: <20160913151543.GE540@e102648.cambridge.arm.com> References: <20160913140236.GC540@e102648.cambridge.arm.com> <20160913151543.GE540@e102648.cambridge.arm.com> From: Ard Biesheuvel Date: Tue, 13 Sep 2016 16:25:32 +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 15:25:34 -0000 Content-Type: text/plain; charset=UTF-8 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. >> 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.