SPARC assembly won't compile, problems with NT headers

[Troy Rollo]

winegcc from the current WineHQ produces assembly output for SPARC systems 
that cannot be processed by the assembler.

1. "operation combines symbols in different segments" error.

This problem arises because the imports code attempts to generate a relocation 
involving symbols in different segments (one in the text segment and one in 
the data segment). SPARC assemblers (including gas on a SPARC) cannot deal 
with relocations involving symbols in different segments. This only affects 
position independent code and can be avoided by changing the assembly code 
output in imports.c to something simpler.

2. "can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data 
section}"

This problem is more sinister. It arises from the same limitation as the first 
problem, but is not susceptible to being worked around. The offending code is 
the code that attempts to generate the NT header of the executable - 
specifically the SizeOfImage element. I can't see any way at this point to 
provide for this calculation to be done until after the linker output is 
generated. I suspect the solution to this problem is to just output a zero in 
this location and have winegcc modify the executable image to insert the 
correct values after the linker has created it.

Does anybody have any objections to this solution or another approach to 
suggest?

-- 
Troy Rollo - wine(a)troy.rollo.name

Typo on download page for debian packages

[Stefan Munz]

Hi,

I don't know who who is responsible for maintaining the website, but probably 
he will read wine-devel ;-)

I found a little typo on the download site for the debian packages. The link 
to the repository works for me only without the space:

deb http://wine.sourceforge.net/apt/ binary/

should be:

deb http://wine.sourceforge.net/apt/binary/

cu,

Stefan

Typo on download page for debian packages

[Andreas Mohr]

Hi,

On Thu, Dec 22, 2005 at 09:20:47AM +0100, Stefan Munz wrote:
> Hi,
>
> I don't know who who is responsible for maintaining the website, but probably 
> he will read wine-devel ;-)
>
> I found a little typo on the download site for the debian packages. The link 
> to the repository works for me only without the space:
>
> deb http://wine.sourceforge.net/apt/ binary/
>
> should be:
>
> deb http://wine.sourceforge.net/apt/binary/

This is not true, and further you could even see it from three locations
that it's not: this line, the screenshot below, and the second line even
further below (and from my own testing which confirmed that it's correct).

Let me guess that you're not a Debian user, right? ;-)

Andreas

Typo on download page for debian packages

[Stefan Munz]

Am Donnerstag, 22. Dezember 2005 10:45 schrieb Andreas Mohr:
> Hi,
>
> On Thu, Dec 22, 2005 at 09:20:47AM +0100, Stefan Munz wrote:
> > Hi,
> >
> > I don't know who who is responsible for maintaining the website, but
> > probably he will read wine-devel ;-)
> >
> > I found a little typo on the download site for the debian packages. The
> > link to the repository works for me only without the space:
> >
> > deb http://wine.sourceforge.net/apt/ binary/
> >
> > should be:
> >
> > deb http://wine.sourceforge.net/apt/binary/
>
> This is not true, and further you could even see it from three locations
> that it's not: this line, the screenshot below, and the second line even
> further below (and from my own testing which confirmed that it's correct).
>
> Let me guess that you're not a Debian user, right? ;-)

Since a few weeks a use kubuntu on my laptop, that's why I was looking on the 
debian download page. But I'm definitely a debian newbie ;-)
My fault was to try the explore the repository with a web browser and take it 
as one url. Sorry for your inconvenience.

cu,

Stefan
> Andreas

-- 
Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz(a)itomig.de
ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de
Sand 14  . . . . . . . . . . . . . . . . . . phone: [phone]
D-72076 Tübingen . . . . . . . . . . . . . . mobil: [phone]

[Alexandre Julliard]

Troy Rollo <wine(a)troy.rollo.name> writes:
> 2. "can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data 
> section}"
>
> This problem is more sinister. It arises from the same limitation as the first 
> problem, but is not susceptible to being worked around. The offending code is 
> the code that attempts to generate the NT header of the executable - 
> specifically the SizeOfImage element. I can't see any way at this point to 
> provide for this calculation to be done until after the linker output is 
> generated. I suspect the solution to this problem is to just output a zero in 
> this location and have winegcc modify the executable image to insert the 
> correct values after the linker has created it.

You can probably fix it by defining an _end symbol, like we do for
MacOS. You certainly don't want to try modifying the binary after it
has been built.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Troy Rollo]

On Thu, 22 Dec 2005 19:52, Alexandre Julliard wrote:
> You can probably fix it by defining an _end symbol, like we do for
> MacOS. You certainly don't want to try modifying the binary after it
> has been built.

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.
-- 
Troy Rollo - wine(a)troy.rollo.name

[Alexandre Julliard]

Troy Rollo <wine(a)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.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Troy Rollo]

On Fri, 23 Dec 2005 19:18, Alexandre Julliard wrote:
> Troy Rollo <wine(a)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(a)troy.rollo.name

[Alexandre Julliard]

Troy Rollo <wine(a)troy.rollo.name> writes:
> 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.

It's relative to the start of the NT header, and it gets relocated at
load time when we map the NT header to its proper place, at the start
of the .text section.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Troy Rollo]

On Wed, 28 Dec 2005 20:38, Alexandre Julliard wrote:
> It's relative to the start of the NT header, and it gets relocated at
> load time when we map the NT header to its proper place, at the start
> of the .text section.

OK. We still have the problem that on a SPARC there is no way at the time of 
assembling the file to generate data that involves taking the difference 
between symbols that are in two different segments. The real "_end" symbol 
exists, and is of course in the BSS segment. Obviously it would be somewhat 
pointless for the NT header to be in the BSS segment, so having the 
SizeOfImage element contain the difference between _end and the start of the 
NT header would appear to be impossible (absent making our own modified 
versions of the GNU linker and assembler), at least at any time before 
completion of the link phase. This leaves AFAICS three obvious alternatives:

1. Modify the executable after the link phase;
2. Put what we can into SizeOfImage (which could only be one part of the 
calculation - presumably "_end") and adjust at load time; or
3. Don't rely on the assembler to put anything meaningful in there and 
calculate the whole thing at load time.

-- 
Troy Rollo - wine(a)troy.rollo.name

[Alexandre Julliard]

Troy Rollo <wine(a)troy.rollo.name> writes:
> 1. Modify the executable after the link phase;
> 2. Put what we can into SizeOfImage (which could only be one part of the 
> calculation - presumably "_end") and adjust at load time; or
> 3. Don't rely on the assembler to put anything meaningful in there and 
> calculate the whole thing at load time.

4. Define an _end symbol in .data, that's good enough for what we
   need.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Segin]

Alexandre Julliard wrote:
> Troy Rollo <wine(a)troy.rollo.name> writes:
> > 1. Modify the executable after the link phase;
> > 2. Put what we can into SizeOfImage (which could only be one part of the 
> > calculation - presumably "_end") and adjust at load time; or
> > 3. Don't rely on the assembler to put anything meaningful in there and 
> > calculate the whole thing at load time.
>
> 4. Define an _end symbol in .data, that's good enough for what we
>   need.

Could you guys fill me in on what's going on with this? Is someone 
trying to compile Wine on a SPARC? I thought Wine was only for x86 and 
x86_64...

[Tony Lambregts]

Segin wrote:
> Alexandre Julliard wrote:
> > Troy Rollo <wine(a)troy.rollo.name> writes:
> > > 1. Modify the executable after the link phase;
> > > 2. Put what we can into SizeOfImage (which could only be one part of the 
> > > calculation - presumably "_end") and adjust at load time; or
> > > 3. Don't rely on the assembler to put anything meaningful in there and 
> > > calculate the whole thing at load time.
> >
> > 4. Define an _end symbol in .data, that's good enough for what we
> >   need.
>
> Could you guys fill me in on what's going on with this? Is someone 
> trying to compile Wine on a SPARC? I thought Wine was only for x86 and 
> x86_64...
>
> ------------------------------------------------------------------------

From our FAQ:

  Wine is being developed specifically to run on the Intel x86 class of CPUs 
under certain UNIXes that run on this platform. Winelib however is capable of 
porting the Windows applications source code to other platforms also, not only x86.

http://www.winehq.org/site/docs/wine-faq/index#UNDER-WHAT-PLATFORMS-WILL-WIN...

The only real limitation of winelib is that it is limited to programs written in 
C and not any other progamming languages.

--

Tony Lambregts

[Eric Frias]

Troy Rollo wrote:
> winegcc from the current WineHQ produces assembly output for SPARC systems 
> that cannot be processed by the assembler.

I've attached the patches we're using for winebuild on SPARC.  This 
fixes both of the problems you're encountering.  I'm not sure if the fix 
is the right one, but it works quite nicely :-)  We use gcc/gas.

Eric

Index: import.c
===================================================================
--- import.c	(.../vendor/wine/current/tools/winebuild)	(revision 31841)
+++ import.c	(.../trunk/wine/tools/winebuild)	(revision 31841)
@@ -314,7 +314,7 @@
         if (odp->flags & FLAG_PRIVATE) continue;
         imp->exports[imp->nb_exports++] = odp;
     }
-    imp->exports = xrealloc( imp->exports, imp->nb_exports * sizeof(*imp->exports) );
+    imp->exports = xrealloc( imp->exports, imp->nb_exports ? (imp->nb_exports * sizeof(*imp->exports)) : 1);
     if (imp->nb_exports)
         qsort( imp->exports, imp->nb_exports, sizeof(*imp->exports), func_cmp );
     return 1;
@@ -835,7 +835,10 @@
     if (!nb_imm) return;
 
     fprintf( outfile, "\n/* immediate import thunks */\n\n" );
-    fprintf( outfile, "\t.text\n" );
+    if (target_cpu == CPU_SPARC)
+        fprintf( outfile, "\t.data\n" );
+    else
+        fprintf( outfile, "\t.text\n" );
     fprintf( outfile, "\t.align %d\n", get_alignment(8) );
     fprintf( outfile, "%s:\n", asm_name(import_thunks));
 
@@ -959,7 +962,10 @@
     if (!nb_delayed) return;
 
     fprintf( outfile, "\n/* delayed import thunks */\n\n" );
-    fprintf( outfile, "\t.text\n" );
+    if (target_cpu == CPU_SPARC)
+        fprintf( outfile, "\t.data\n" );
+    else
+        fprintf( outfile, "\t.text\n" );
     fprintf( outfile, "\t.align %d\n", get_alignment(8) );
     fprintf( outfile, "%s:\n", asm_name(delayed_import_loaders));
     fprintf( outfile, "\t%s\n", func_declaration("__wine_delay_load_asm") );
@@ -1147,7 +1153,10 @@
     for (i = 0; i < ext_link_imports.count; i++)
         fprintf( outfile, "\t%s %s\n", get_asm_ptr_keyword(), asm_name(ext_link_imports.names[i]) );
 
-    fprintf( outfile, "\n\t.text\n" );
+    if (target_cpu == CPU_SPARC)
+        fprintf( outfile, "\t.data\n" );
+    else
+        fprintf( outfile, "\t.text\n" );
     fprintf( outfile, "\t.align %d\n", get_alignment(get_ptr_size()) );
     fprintf( outfile, "%s:\n", asm_name("__wine_spec_external_link_thunks") );
 
@@ -1239,6 +1248,15 @@
     output_delayed_imports( outfile, spec );
     output_immediate_import_thunks( outfile );
     output_delayed_import_thunks( outfile, spec );
+
+    if (target_cpu == CPU_SPARC)
+        {
+        /* DJANKOV Q&D */
+        fprintf( outfile, "\n\t.data\n" );
+        fprintf( outfile, "\t.align %d\n", get_alignment(4) );
+        fprintf( outfile, "%s:\n", asm_name("_end") );
+        fprintf( outfile, "\t.long 0\n" );
+        }
     output_external_link_imports( outfile, spec );
     if (nb_imports || ext_link_imports.count || has_stubs(spec)) output_get_pc_thunk( outfile );
 }