[ofw] Vista supported?

Tue May 29 17:26:48 PDT 2007

I guess we can do the workaround as you suggest (that is either use
padding or a union which would only be a change to the struct
themselves).

We would probably have to wait for the OFED release before we switch our
compiler though.

Another issue that I saw with the new compiler is that if I open many
applications compiling takes much longer. I wander if anyone has seen
this or has some idea of how to solve this issue.

Thanks
Tzachi

________________________________

	From: Jan Bottorff [mailto:jbottorff at xsigo.com] 
	Sent: Wednesday, May 30, 2007 1:56 AM
	To: Tzachi Dar; Mirko Benz; ofw at lists.openfabrics.org
	Subject: RE: [ofw] Vista supported?

	Hi,

	Yes, I know about the suggestion on NTDEV, I was the person who
started the thread.

	The workaround is fine for my trivial test example, but
unfortunately, it would take changing the IB stack sources in many
places to use this workaround. If we could find a workaround that only
needed to change the structure declaration (like explicitly adding a pad
field on 32-bit builds) it would be much easier. Changing EVERY call
point is a lot of changes. 

	- Jan

________________________________

	From: Tzachi Dar [mailto:tzachid at mellanox.co.il] 
	Sent: Saturday, May 26, 2007 1:32 PM
	To: Jan Bottorff; Mirko Benz; ofw at lists.openfabrics.org
	Subject: RE: [ofw] Vista supported?

	Hi,

	As far as for the compiler bugs it seems that it has a simple
workaround, see bellow for ideas that I have.

	The main issue that I currently see is that we are getting close
to a new release, and replacing the compiler so close to a release is
not that good idea. As you said, for now we can continue based on the
binary computability of vista.

	Thanks
	Tzachi

	2 ways in order to work around the compiler bugs:
	As remembered the problem is because we have to make sure that
we reserve 64 bit for a pointer even on 32 bit systems. The obvious way
to do this is to use __ptr64 that doesn't work on new builds.
	1) As was suggested in the OSR forum, one can simply change the
struct to use a union of the pointer and some 64 bits value.
	2) one can use the same struct as before but do some other
thing:
	void test(long val)
	{
	        if (val == 0)
	                return;

	        // the following line crashes the 6000/6001 WDK 32-bit
compiler with
	        // error C1001: An internal error has occurred in the
compiler.
	        //var1->funcPtr(0);
	        var2 = var1->funcPtr;
	        var2(0); // Very ugly but Compiles well
	}

	> -----Original Message-----
	> From: ofw-bounces at lists.openfabrics.org
	> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Jan
Bottorff
	> Sent: Friday, May 25, 2007 10:21 PM
	> To: Mirko Benz; ofw at lists.openfabrics.org
	> Subject: RE: [ofw] Vista supported?
	>
	> I know the WinIB source tree will not compile with the Vista
	> (or later) WDK (at least will not compile for checked 32-bit
	> platforms). The problem is the compiler aborts when
	> processing __ptr64 pointers inside a structure. The WinIB
	> stack uses this in LOTS of places.
	>
	> I'm not super optimistic about Microsoft fixing the compiler
	> anytime soon, because I also see compiler bugs in the code
	> generation for InterlockedAnd (and other Interlocked
	> functions) that have been know for more than a year, are not
	> fixed. The most recent WDK betas seems to have a fix for
	> InterlockedAnd in the debug build, but the free build still
	> gets it wrong.
	>
	> The following will reproduce the __ptr64 bug:
	>
	>
---------------------------------------------------------------
	> #include <ntddk.h>
	>
	> struct {
	>       void (* __ptr64 funcPtr)(long val); } *var1;
	>
	>
	>
	>
	> void test(long val)
	> {
	>       if (val == 0)
	>               return;
	>
	>       // the following line crashes the 6000/6001 WDK 32-bit
	> compiler with
	>       // error C1001: An internal error has occurred in the
compiler.
	>       var1->funcPtr(0);
	> }
	>
	> NTSTATUS DriverEntry(PDRIVER_OBJECT  DriverObject,
PUNICODE_STRING
	> RegistryPath)
	> {
	>       var1->funcPtr = &test;
	>       test(1);
	>       return STATUS_SUCCESS;
	> }
	> --------------------------------------------------------------
	>
	> The InterlockedAnd bug shows up in code like:
	>
	> // atomic test and clear
	> If (InterlockedAnd(&flag, 0)) {
	>       // this code never executes
	>       // InterlockedAnd is documented to return the old value
	>       // but actually returns the modified value }
	>
	> Binaries compiled using the W2k3 SP1 DDK can run on Vista,
	> but doing development on the latest tools is a serious
	> problem. I view it a Microsoft problem, since it was
	> something in the Vista (and later) WDK compiler that broke.
	>
	> - Jan
	>
	>
	> -----Original Message-----
	> From: ofw-bounces at lists.openfabrics.org
	> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Mirko
Benz
	> Sent: Friday, May 25, 2007 1:38 AM
	> To: ofw at lists.openfabrics.org
	> Subject: [ofw] Vista supported?
	>
	> Hi,
	>
	> What is the status of support for Vista? Should SRP work?
	>
	> Regards,
	> Mirko
	> _______________________________________________
	> ofw mailing list
	> ofw at lists.openfabrics.org
	> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
	> _______________________________________________
	> ofw mailing list
	> ofw at lists.openfabrics.org
	> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
	> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20070530/ba176aed/attachment.html>