From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BF1571A1EE3 for ; Wed, 5 Oct 2016 12:24:52 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 189so21039046ity.1 for ; Wed, 05 Oct 2016 12:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DGhZjKNnbB5E54j7/iz99q6qHtA9GINW2bcvRlAW8Pw=; b=ca12W3BoBgzXSAsSYA6seIX5m+ookKRSod3jzvxQGQ4SCWu+M5g+cvmWENiwIGPN1B FVaNVJ8miDMbO8PCevPI+y55Ivol69F+W8ZeY1j4twGqBrzdLA9HvePYYcDEZEShyyFY TQ9c47X3YRMO/E8m0rebgrBwi5ruYdHuFQDauomltWNHYcX3v7IJ3bzQgcyX9L66VK4k GXvDAXIbH9c2IfNm3M7oslmHm2TTQDiDJ8PiNsMhY/VcjJdiUpqh48dp9IJYc5W8oyww Z8apUzZ4mZKcwYzbHAy+jCKoyXVj+kR15U626aBnhPFiH2imTsDb/I8M/wDUg2Fd8gjf ip/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DGhZjKNnbB5E54j7/iz99q6qHtA9GINW2bcvRlAW8Pw=; b=kvjtvKTt7RJx3GKSTP3m/ZcsTiFjYaIcZAC7cIkeDQePQBoPCb6CkKM9ujQUAIqGre 2O6jRalhdM5hZ2ZVRVQIdKyiLYeTDFlc24GfoH1SaLWFOyK6+SJsTs7kX3rHnu3Ryq82 0mHj/NM6lTWMFxkn51Xmj2hZa3+0bAPvGt/lmLOyKT6n2asuSHAREHLIjFtJYoRSKRdz cky1YwG/HniXX0YUvctAqv7ftmAbWfiy4RRug4j1M9X1hQqKI3jwlEbYzrZhawSKy/Pg xWP6zq8yEvF6Ke2Z4ym0M9GUK9niovu+RRvKViu9Uc+7hJPTDcEzGvgIL+fMqFNJB92a Mg6Q== X-Gm-Message-State: AA6/9Rkc1wisVrq3A3G4GsNT9qfS1GRxBdkmmK1tt3F0K4a2dMeBw3hyj4oyCEnNmZFlD4Ds4mAtVQ0fQoNCOw== X-Received: by 10.36.50.149 with SMTP id j143mr10635179ita.91.1475695492208; Wed, 05 Oct 2016 12:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.203.132 with HTTP; Wed, 5 Oct 2016 12:24:51 -0700 (PDT) In-Reply-To: <68CAE063-1A6B-493B-B728-B2991F018DC6@apple.com> References: <68CAE063-1A6B-493B-B728-B2991F018DC6@apple.com> From: valerij zaporogeci Date: Wed, 5 Oct 2016 22:24:51 +0300 Message-ID: To: Andrew Fish Cc: edk2-devel 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 19:24:53 -0000 Content-Type: text/plain; charset=UTF-8 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. 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? :)