Re: Yasm r1713 fixed; building and Windows-native

On Dec 19, 2006, at 6:46 PM, Wolfgang Thaller wrote:
> On 19-Dec-06, at 9:10 PM, Peter Tanski wrote:
>> As you would expect, there are few areas where mingw32- 
>> conditional  HOST settings really overlap the TARGET settings,  
>> notably code in /compiler/cmm/CLabel.hs and compiler/nativeGen/ 
>> PositionIndependentCode.hs.
>
> Well, whenever there is "mingw32" in CLabel.hs or  
> PositionIndependentCode.hs, what is really meant is "windows". If  
> there is any HOST conditional there, then that's probably a bug.

Thanks!  So it would probably be better to test for three alternative  
defines: mingw32, cygwin and windows.  (The new define for "Windows- 
native" is i386_unknown_windows, target: windows_TARGET_OS; dynamic  
cross-compilation of x86_64 code might be supported under an -mcpu or  
-mtune flag, like gcc's -mcpu=x86_64.)

For CLabel.hs and PositionIndepentCode.hs all the mingw32 defines are  
to TARGET_OS, so no bugs :)  The problem is where mingw32 and cygwin  
differ from Win32 or Win64--I don't know enough of their internals to  
tell; so far I am sticking with the PE-COFF spec and haven't yet  
learned about any differences in calling conventions between mingw,  
cygwin and windows.

>> Ian: do you think some of the problems with the cygwin build might  
>> be related to this line in compiler/cmm/CLabel.hs:584 (labelDynamic):
>> 	#if mingw32_TARGET_OS
>> 	   ForeignLabel _ _ d  -> d
>> 	#else
>> that is, labelDynamic might give false positives for dynamic code  
>> on cygwin?
>
> It will probably cause problems for foreign functions that are  
> *not* imported from a DLL. It should cause linker errors involving  
> undefined __imp__foo symbols (is that the kind of breakage that  
> occurs in the cygwin build?).

Ian posted problem with cygwin in a message, "Build failure on  
Windows," at http://www.haskell.org/pipermail/cvs-all/2006-December/ 
052191.html .  The failures are undefined references to functions in  
libHSWin32.a, but I haven't looked at the real symbols to see if they  
have the __imp__ prefix--from the linker response, i.e.,  
"DeleteObject", they don't seem to.

> Windows tolerates false negatives for imported functions (and even  
> for imported data with recent GNU linker versions), and I think  
> that "d" flag in the ForeignLabel is never set correctly by other  
> code, so it is probably always False.

 From my perspective that is good news: no differences, change is  
easy :)

Cheers,
Pete