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:[email protected]] On Behalf Of
> Andrew Fish
> Sent: Thursday, October 06, 2016 8:08 AM
> To: valerij zaporogeci <[email protected]>
> Cc: edk2-devel <[email protected]>
> Subject: Re: [edk2] TE relocations
> 
> 
> > On Oct 5, 2016, at 4:25 PM, valerij zaporogeci <[email protected]> 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
> > [email protected]
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to