From: Achin Gupta <achin.gupta@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: Relocation fixup during AARCH64 SEC PE-COFF generation?
Date: Tue, 13 Sep 2016 16:16:17 +0100 [thread overview]
Message-ID: <20160913151543.GE540@e102648.cambridge.arm.com> (raw)
In-Reply-To: <CAKv+Gu8BuYOKoPPZ_GAyDwqHvJ1x_4hzvi3zQDibm1ctO4qV=A@mail.gmail.com>
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.
> 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"?
cheers,
Achin
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next prev parent reply other threads:[~2016-09-13 15:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-13 14:03 Relocation fixup during AARCH64 SEC PE-COFF generation? Achin Gupta
2016-09-13 14:12 ` Ard Biesheuvel
2016-09-13 14:43 ` Ard Biesheuvel
2016-09-13 15:16 ` Achin Gupta [this message]
2016-09-13 15:25 ` Ard Biesheuvel
2016-09-13 15:55 ` Achin Gupta
2016-09-13 16:01 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160913151543.GE540@e102648.cambridge.arm.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox