From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 DC1631A1E31 for ; Wed, 5 Oct 2016 13:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1475701114; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=P30W8WeQBTA/iozseciZG5tcLZFGd6z2FtB9cCmXEi4=; b=USlSUM4QYXTSsff/JmXnT2NgG/iXbRv3MRgLLvItidTu2KISIGOmYZFeWtRjHjY9 teCnEqpnXgEU/Yi6KUw2eg4bTEhetXn2qVw5VLYNlw1zNCvIPwYb65s3ndO1ZZ7u y+Sp/sr7eqKiNyoRM07rLQ8+LG4wjlO8auFUMUlfLOPiOs2gVhFUe6Z5qn961l6e MrhaerfkRI+L1SUEfi8WWQC21ywMSlUm7u4yXH/11fhpmX1pUeCb9AFR6xWYvsdl WbBMTV1yjJj3etCFpdQOmUId/kovgMkC2eFZekEgpM2t1UrINSUgsHfwPQhxWt91 qWJSNEUpBlVnuCgy9vHebg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 0A.09.07001.A7965F75; Wed, 5 Oct 2016 13:58:34 -0700 (PDT) X-AuditID: 11973e12-23e0e9a000001b59-8c-57f5697aed87 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay6.apple.com (Apple SCV relay) with SMTP id 98.1A.23613.A7965F75; Wed, 5 Oct 2016 13:58:34 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.37.250] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OEL00FA3E9L2600@nwk-mmpp-sz13.apple.com>; Wed, 05 Oct 2016 13:58:34 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <85365CC4-AEB9-41F3-9F71-A32A0AFF4588@apple.com> Date: Wed, 05 Oct 2016 13:58:33 -0700 In-reply-to: Cc: edk2-devel To: valerij zaporogeci References: <68CAE063-1A6B-493B-B728-B2991F018DC6@apple.com> X-Mailer: Apple Mail (2.3226) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUi2FAYpVuV+TXcYPVWZYs9h44yWzz+187s wOSxc9Zddo/u2f9YApiiuGxSUnMyy1KL9O0SuDJuLzzIWHDHu2LCpmVMDYwH7LsYOTkkBEwk Lqw7zQxiCwnsZZS48doMJr7+yE/WLkYuoPghRomz84+BFfEKCEr8mHyPpYuRg4NZIEzi1qp0 iJp3jBIPbzWyg9QIC4hLvDuzCayeTUBZYsX8D+wQvTYST291MEPUKEksbZwHFmcRUJU49ucL I8hMToFgif3fUkDCzAIaEl9XbwcrERHQkTh4/yIzxK4zQPfcfskEUi8hICsx+5cXSFxC4DKb xMsbW1kmMArNQnLqLIRTZ4GN1ZL4/qgVKiwvcfC8LERYU+LZvU/sELa2xJN3F1gXMLKtYhTK TczM0c3MM9FLLCjISdVLzs/dxAiKgul2QjsYT62yOsQowMGoxMN7Q/VruBBrYllxZe4hRmkO FiVxXtYPn8OFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MKrl85a/vvys97NH9vY7nus2hpzX EfiwzWLdtYx83vZjVeeln9pOFtFXuFe3LfLm32dW5+OFb3zpm7Rp7vraUN4f25N41P30Fj14 IX/Agd/nNvftXebbn647e3q57vxvaice9mwN69zU/v1662H96c9FnhhaGW+785Tz6pnQB8p9 fxOrLx5bVpCqxFKckWioxVxUnAgANzh522MCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUi2FB8Q7cq82u4wY97chZ7Dh1ltnj8r53Z gclj56y77B7ds/+xBDBFcdmkpOZklqUW6dslcGXcXniQseCOd8WETcuYGhgP2HcxcnJICJhI rD/ykxXCFpO4cG89WxcjF4eQwCFGibPzjzGDJHgFBCV+TL7H0sXIwcEsECZxa1U6RM07RomH txrZQWqEBcQl3p3ZBFbPJqAssWL+B3aIXhuJp7c6mCFqlCSWNs4Di7MIqEoc+/OFEWQmp0Cw xP5vKSBhZgENia+rt4OViAjoSBy8f5EZYtcZoHtuv2QCqZcQkJWY/ctrAqPALCTXzUK4bhbY JC2J749aocLyEgfPy0KENSWe3fvEDmFrSzx5d4F1ASPbKkaBotScxEozvcSCgpxUveT83E2M 4HAujNrB2LDc6hCjAAejEg/vDdWv4UKsiWXFlbnAEOJgVhLh5UoDCvGmJFZWpRblxxeV5qQW H2KcyAj04kRmKdHkfGC05ZXEG5qYGJgYG5sZG5ubmNNSWEmcd/flT+FCAumJJanZqakFqUUw RzFxcEo1MHLdf+Lpk6Z4ZpZq0Pr0M2vqZrroRN8/InzJ0vDIrMKHt9bxHuUxenPIN8cpZMLk E6a7xJQPrNx60l6NeZ7Etl1/t/5xt5my0qR8YmLLO9eDS7/mCsilZUzTbQ/MlwlZ9uxRoc/5 mimRRrUvjif5t0VGyq/evnS3uOxJmWVhiTVv7H/c15rcMUWJpTgj0VCLuag4EQAg23BL2gIA AA== X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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: Wed, 05 Oct 2016 20:58:35 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > On Oct 5, 2016, at 12:24 PM, valerij zaporogeci wrote: > > Thank you, Andrew, I guess I understood. PE/TE images get relocated at > FV creation time, they execute directly from FV and they are linked at > where they really will lie in XIP memory. Pedantically speaking PE/TE images are not linked at FV creation time they are relocated to the XIP address. For the most part this is the same thing that EFI does when it loads the PE/TE image into malloced memory. > And the alignment value > chosen is not that minimum of 512 byte, mentioned in the PE > specification. Now it's clear. The only thing I still don't get is > that: > Suppose you have your input PE image, which you need to translate in > TE. It's linked at 0. It has a code section and it is lying (in the > file) at the first available 20h aligned offset right after all the > headers. Now you make translation into TE following the specification > algorithm. It says you should strip away all not needed stuff from the > beginning of the PE file, then put TE header instead (28h byte) and > right after it you should place all the remaining PE content. But > constructed this way TE, will break absolute referencies in the code. > Suppose some code references some data, using its address: address = > :0 + + . Where > DataSectionBase is the offset of the beginning of the section from the > ImageBase, thus its RVA. ImageBase remains the same - 0, SectionOffset > too, but _actual_ DataSectionBase, would not be the same for the newly > created TE, because stripping got the data section closer to the file > beginning. Every reference to the data would be broken. Base > relocation at the FV creation won't help, since it changes ImageBase > (from 0 to "ROM address"), it doesn't fix DataSectionBase mismatch. If > after PE->TE translation, "somehow" DataSectionBase remains the same, > then what space saving it is? :) I don't think you are Groking the simplicity inherent in the TE design. The image layout of a PE/COFF or TE image is the same. >>From low address to hight address: IMAGE_HEADER SECTION_TABLE .text SECTION .data SECTION .reloc SECTION .debug SECTION The 1st section after the SECTION_TABLE is going to start on a section alignment boundary, and each subsequent section will start on the aligned boundary. >>From the PE/COFF point of view it is only the system that cares about the PE/COFF header not really the code that executes. So the image does not really care that it is TE or PE/COFF. I'll use P for PE/COFF header and T for TE header to make my point. P P P PT ---- SECTION_TABLE --- .text SECTION .data SECTION .reloc SECTION .debug SECTION This layout is the basic reason that debuggers work even though they don't understand TE. When you tell a debugger the start location of a TE image you actually give the debugger the start of P. There is info in the TE header that lets you calculate the location that would have been the start of the PE/COFF header. Conceptually it is the space before the TE image (P but no T) that is being saved in the ROM by using the TE format. Feel free to look at the code, https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffLib/BasePeCoff.c , that decodes PE/COFF and TE. Thanks, Andrew Fish PS It is a little tricky to actually look at TE images in the build output. All the modules get constructed as PE/COFF. If you search the Build/ directories for .te files these are a TE Section in the FV, thus they start with a 4 byte section header. If you remove the 1st 4 bytes you get a TE Image.