public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gao, Liming" <liming.gao@intel.com>
To: Andrew Fish <afish@apple.com>, valerij zaporogeci <vlrzprgts@gmail.com>
Cc: edk2-devel <edk2-devel@lists.01.org>,
	"Gao, Liming" <liming.gao@intel.com>
Subject: Re: TE relocations
Date: Sat, 8 Oct 2016 08:54:57 +0000	[thread overview]
Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14B481E27@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <065FA275-0EA3-4516-87EE-233AFF226C58@apple.com>

If TE is loaded such that TE header is placed in memory at THE SAME ImageBase address as the original PE would have been,  its mapped original PE ImageBase will be adjusted to the begin of the TE image + sizeof (EFI_TE_IMAGE_HEADER) - StrippedSize. Then, its mapped PE image will be relocated based on this address. So, there is no issue here.  You can see the code edk2\MdeModulePkg\Core\Pei\Image\Image.c line 474. When load TeImage, the allocated memory address is for PE ImageBase, then PE ImageBase will skip the reserved space for the stripped PeHeader and be changed to TE image base. 

As Andrew point, some platform has enabled TE image for PeiCore and PEIM. In build process, GenFw tool will be used to convert PE image to TE image, GenFfs tool integrate TE image into FFS, and GenFv tool will combine all FFS into FV image. GenFv tool will rebase all TE/PE image as their address in FV image to make them become XIP. In this process, GenFw will check whether PE image has the same section and file alignment. If not, GenFw can't convert it to TE image. 

Thanks
Liming
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Andrew Fish
> Sent: Thursday, October 06, 2016 8:08 AM
> To: valerij zaporogeci <vlrzprgts@gmail.com>
> Cc: edk2-devel <edk2-devel@lists.01.org>
> Subject: Re: [edk2] TE relocations
> 
> 
> > On Oct 5, 2016, at 4:25 PM, valerij zaporogeci <vlrzprgts@gmail.com> wrote:
> >
> >>> The ImageBase is the same for PE/COFF and TE.
> >>> In the code ImageAddress points to the start of T or P (well P can have a
> DOS header
> >>> prepended etc). I think a lot of the code operates on ImageAddress and
> thus needs the
> >>> adjustment.
> >
> > Well, I don't want to abuse your attention.
> 
> Well I'm doing it off the top of my head so I'm not doing a lot of research. If I
> get a chance at some point I'll re-read the PI spec and see if is a bug in the
> specification since I can file an ECR to get it fixed.
> 
> > Just last try to explain
> > the incosistency here I can not resolve.
> > Suppose we have some imaginable ISA instruction somewhere in code:
> > LOAD r1, [0x402f04bc]
> > and 0x402f04bc is the address of some symbol, resolved by linker.
> > let's parse this address. Let ImageBase be 0x402f0000, and data
> > section offset be 0x400 and finally data item offset in the section be
> > 0xbc. Data section is also at 0x400 from the file beginning, since
> > sectionalignment==filealignment, which means the layout is the same.
> > When it is loaded at 0x402f000, everything works. Data section is at
> > 0x400 from there, and our variable is at 0xbc from the section start.
> > Now, we make TE from it. Now, the data section in the TE file is NOT
> > at 0x400 from the file beginning (it is closer). And when (and if) TE
> > is loaded such that TE header is placed in memory at THE SAME
> > ImageBase address as the original PE would have been, the referenced
> > variable will not be at 402f04bc. And the code, referencing address
> > 0x402f4bc, would get something else instead of this variable content.
> > This is not the case in the reality. But why? The PI specification
> > recipe, with only AddressOfEntryPoint adjustment and without
> > adjustment of anything else referenced (in the code) should result in
> > this incostistency.
> 
> Quick answer is sectionalignment==filealignment for XIP is from the PE/COFF
> image point of view. From a TE point of view the FileAlignment has to get
> adjusted. But please remember TE is really just a shortened version of the
> PE/COFF header, so other than references to those header values it is still
> the PE/COFF image.
> 
> So I have to ask why are you so interested in TE?
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


      parent reply	other threads:[~2016-10-08  8:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-05 15:08 TE relocations valerij zaporogeci
2016-10-05 16:51 ` Andrew Fish
2016-10-05 19:24   ` valerij zaporogeci
2016-10-05 20:58     ` Andrew Fish
2016-10-05 21:45       ` valerij zaporogeci
2016-10-05 22:11         ` Andrew Fish
2016-10-05 23:25           ` valerij zaporogeci
2016-10-06  0:07             ` Andrew Fish
2016-10-06 13:01               ` valerij zaporogeci
2016-10-08  8:54               ` Gao, Liming [this message]

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=4A89E2EF3DFEDB4C8BFDE51014F606A14B481E27@shsmsx102.ccr.corp.intel.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