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

_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot

Reply via email to