From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 73B3D1A1E82 for ; Sat, 8 Oct 2016 01:55:01 -0700 (PDT) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP; 08 Oct 2016 01:55:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,311,1473145200"; d="scan'208";a="17957943" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga004.jf.intel.com with ESMTP; 08 Oct 2016 01:55:00 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sat, 8 Oct 2016 01:55:00 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.15]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.118]) with mapi id 14.03.0248.002; Sat, 8 Oct 2016 16:54:58 +0800 From: "Gao, Liming" To: Andrew Fish , valerij zaporogeci CC: edk2-devel , "Gao, Liming" Thread-Topic: [edk2] TE relocations Thread-Index: AQHSHxpyjlai+OLjYkGL0sPCisafR6CZjQMAgAAq9YCAABougIAADQCAgAAHZYCAABSygIAAC9aAgAQ0OCA= Date: Sat, 8 Oct 2016 08:54:57 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14B481E27@shsmsx102.ccr.corp.intel.com> References: <68CAE063-1A6B-493B-B728-B2991F018DC6@apple.com> <85365CC4-AEB9-41F3-9F71-A32A0AFF4588@apple.com> <065FA275-0EA3-4516-87EE-233AFF226C58@apple.com> In-Reply-To: <065FA275-0EA3-4516-87EE-233AFF226C58@apple.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: TE relocations 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: Sat, 08 Oct 2016 08:55:01 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If TE is loaded such that TE header is placed in memory at THE SAME ImageBa= se address as the original PE would have been, its mapped original PE Imag= eBase 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 o= n this address. So, there is no issue here. You can see the code edk2\MdeM= odulePkg\Core\Pei\Image\Image.c line 474. When load TeImage, the allocated = memory address is for PE ImageBase, then PE ImageBase will skip the reserve= d space for the stripped PeHeader and be changed to TE image base.=20 As Andrew point, some platform has enabled TE image for PeiCore and PEIM. I= n build process, GenFw tool will be used to convert PE image to TE image, G= enFfs 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 conv= ert it to TE image.=20 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 > Cc: edk2-devel > Subject: Re: [edk2] TE relocations >=20 >=20 > > On Oct 5, 2016, at 4:25 PM, valerij zaporogeci wr= ote: > > > >>> 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 ha= ve a > DOS header > >>> prepended etc). I think a lot of the code operates on ImageAddress an= d > thus needs the > >>> adjustment. > > > > Well, I don't want to abuse your attention. >=20 > Well I'm doing it off the top of my head so I'm not doing a lot of resear= ch. If I > get a chance at some point I'll re-read the PI spec and see if is a bug i= n the > specification since I can file an ECR to get it fixed. >=20 > > 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=3D=3Dfilealignment, 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. >=20 > Quick answer is sectionalignment=3D=3Dfilealignment for XIP is from the P= E/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 th= e > PE/COFF header, so other than references to those header values it is sti= ll > the PE/COFF image. >=20 > So I have to ask why are you so interested in TE? >=20 > Thanks, >=20 > Andrew Fish >=20 >=20 > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel