On Fri, 23 Dec 2005 19:18, Alexandre Julliard wrote:
Troy Rollo wine@troy.rollo.name writes:
This will work if (and only if) the value of SizeOfImage is unimportant for Winelib executables. Of course in that case there is probably some merit in setting it to zero anyway since at least that would make it obvious that it has no meaningful value if somebody reads it later.
Some apps do read it. It doesn't have to be exact, but it has to make sense (like being beyond the last section, things like that), so setting it to zero won't work.
That's what I thought, which is why I suggested modifying the output file after the link step. The problem occurs at assembly time rather than link time. The assembler has no knowledge of what segment _end is in, and so assumes it is in a segment that is different from the segment of *every* other symbol. It cannot produce relocation records performing operations on symbols that are in different segment, presumably due to a limitation in the object file format (I have not investigated this too closely since I have assumed that if the file format could handle it then the GNU assembler, at least, would have implemented it, as it has for x86).
On the other hand it seems this field ends up with the wrong value under x86 anyway, since the calculation is "_end - .L__wine_spec_rva_base". ".L__wine_spec_rva_base" is in ".data", which in kernel32.dll.so on my system is section 21 at 0xb6940 - well after ".text". which is section 9 at 0x15000.
According to MS, SizeOfImage should be "Size of the image, in bytes, including all headers." Right now it is much less than that even on the x86 platforms.