On 02/20/2019 07:12 PM, Heinrich Schuchardt wrote:
On 2/18/19 1:52 AM, AKASHI Takahiro wrote:
Heinrich,
On Sat, Feb 16, 2019 at 08:50:43PM +0100, Heinrich Schuchardt wrote:
All code and data sections of PE images are already in the correct relative location when loaded into memory. There is not need to copy them once again.
While I'm not very familiar with how PE image is created (in EDK2),
The relevant reference is the Microsoft Portable Executable and Common Object File Format Specification. The latest version as PDF that I found is revision 11, Jan 23rd, 2017. The citations are from that version. Later versions are available as HTML.
what I understand in Alex's code is
- All the code and data are located starting 0x0 (in virtual space)
The header provides a field ImageBase. If you load the image at this address there is no need for relocation. I could not find any rule saying ImageBase has to be zero. It has be a multiple of 64 KiB. For Windows non-zero defaults are provided in the spec.
- Sections in PE image may not be sorted in ascending order
The spec says: "The physical offset for section data is the same as the RVA". The relative virtual address is defined as "In an image file, the address of an item after it is loaded into memory, with the base address of the image file subtracted from it."
- There may be some gaps (more than one page) between sections, probably, due to alignment requirements or BSS
Yes, due to alignment there may be some gap filling bytes.
Do you say that those assumptions are no longer correct?
The most important sentence concerning relocations in the spec is:
"If the image is loaded at its preferred base, ... the base relocations do not have to be applied."
Yes, but image loading also implies that we actually load the sections to particular offsets with particular section alignment. You can have a PE binary that aligns its sections in 32 byte granule, but expects the sections to get loaded at 4kb alignment. In such a case, I don't see how we can get away to not copy the image.
Alex