SPARC assembly won't compile, problems with NT headers

[Troy Rollo]

On Fri, 23 Dec 2005 19:18, Alexandre Julliard wrote:
> Troy Rollo <wine at 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.

-- 
Troy Rollo - wine at troy.rollo.name