[ofw] RE: patches for depreciated ExAllocatePool() calls

[Leonid Keller]

Hi Jan, 

There is an obvious solution to this problem: to remove __ptr64 from all
the internal structures of OFW stack and to 
replace '<type> __ptr64 *' (and SIZE_T, if any) types in the ioctl
structures by uint64_t with the appropriate 
casting.
Would you like to do that as a part of your "battle" with WDK compiler ?
:)

Leonid

> -----Original Message-----
> From: ofw-bounces at lists.openfabrics.org 
> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Jan Bottorff
> Sent: Thursday, December 20, 2007 2:57 AM
> To: Smith, Stan; Tzachi Dar
> Cc: ofw at lists.openfabrics.org
> Subject: RE: [ofw] RE: patches for depreciated ExAllocatePool() calls
> 
> >WSDK for Windows Server 2008 RC0 - WinDDK 6001.17051 Not ready for 
> >prime-time yet....cl encounters internal compiler error on
> >x86 build of ibal   :-(
> 
> We spent a bunch of time trying to get the IB stack to build 
> with the WDK (6000 or earlier 6001), without total success.
> 
> The compiler internal error you talk about is know. Microsoft 
> has an bug recorded in August 2007 as "Windows OS Bugs : 
> 2014888". We were told it's a long path for a compiler fix to 
> eventually make it into the WDK. 
> 
> The root cause is incorrect compiler processing of __ptr64 
> operations when the pointer is inside a structure. A work 
> around is to specify the /Os compiler optimization option for 
> projects/files that have this failure.
> 
> A sticky problem we came across is the behavior of how 
> __ptr64 pointers are converted has changed between the DDK 
> and WDK. In one case, there is I believe a global variable 
> pointer initialized with (-1). The compiler expands this into 
> a 64-bit wide value of 0xFFFF FFFF FFFF FFFF (on 32-bit 
> builds). This __ptr64 value is assigned to the default 
> destroy function pointer in the IBAL function array, which is 
> not defined with __ptr64. The end result is eventually, when 
> the destroy callback function pointer is used in some 
> operations, its __ptr64 value is 0xFFFF FFFF and a 64-bit 
> compare is used against the global with a value 0xFFFF FFFF 
> FFFF FFFF, which is false. This results in a failure. I 
> believe the DDK compile sign extended the 0xFFFF FFFF into 
> 0xFFFF FFFF FFFF FFFF (which was wrong) when the pointer 
> without __ptr64 is assigned to the pointer with __ptr64. 
> 
> There is no compiler error/warning when this __ptr64 mismatch 
> happens, your code just crashes or run incorrectly. We didn't 
> have a good way to verify every place in the IB stack this 
> MIGHT have this problem. On though is perhaps we should just 
> remove all the __ptr64 attributes and use some other 
> strategy. My understanding is the purpose of __ptr64 is to 
> make some structure have the same shape between 64-bit and 
> 32-bit user mode. This is needed when you run 32-bit apps on 
> 64-bit OS's. This also means test code for correct __ptr64 
> should include 32-bit user mode code running on a 64-bit OS.
> 
> Jan
> 
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>