> On Oct 5, 2016, at 12:24 PM, valerij zaporogeci <vlrzpr...@gmail.com> 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 = > <ImageBase>:0 + <DataSectionBase> + <SectionOffset>. 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 <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. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
