I don’t work on the code that had the issue anymore, so will have to depend
on a few searches…
One of the messages I posed about the issue was at
http://lists.openfabrics.org/pipermail/ofw/2007-December/001852.html
Another message from other people working on the issue can be found at
http://lists.openfabrics.org/pipermail/ofw/2008-February/002002.html
The compiler crashing bug related to __ptr64 was recorded in the Microsoft
bug database in August 2007 as “Windows OS Bugs : 2014888”.
Part of the problem with pointer signeness was the compiler generated
inconsistent code when dealing with __ptr64 attributed variables. For
example, as I remember, if you compared pointers, in 32-bit code, that had
the __ptr64 attribute, all 64-bits allocated were compared. When you
assigned to a 32-bit pointer with the __ptr64 attribute, 32-bits were
assigned. If the __ptr64 value was in a structure, and you zero filled the
structure, and you compared two such pointers, it was ok. If you had a local
variable, which will not normally be in zero filled memory, the comparison
was bogus, and how it failed could depend on what trash was left in what’s
now the stack frame in the upper 32-bit of the __ptr64 ptr.
My memory of an example of pointer signness issues was some code that
initialized a global pointer to -1. This global value was then used to
initialize some other pointers with a magic value. When the code then
compared the pointer to -1, it didn’t match. My memory is the sign extension
behavior of a statically initialized global was different than the behavior
of assignments between pointers.
I know at my company, at least 6 man-weeks (probably more) were spent
fooling with this. I don’t know how many man-weeks were spent by the people
working on the Infiniband stack full time (which included developers at
Intel, Mellanox, and Microsoft). I heard thousands of lines of code (on a
300k line project) eventually had to be changed, all to fix changes in the
compiler between the W2K3 SP1 DDK and Vista WDK (not sure which revision).
Since the Infinband stack is open source, you could probably find the
exactly deltas if you really wanted to.
It’s possible this only effected code that used __ptr64 (and I suppose
__ptr32 if you had 32-bit client code on a 64-bit OS). Without these, there
is no such thing as a 32-bit and 64-bit pointer types in the same module.
My point remains, moving from the W2K3 SP1 DDK to the WDK’s can be
difficult, although typically it’s easy. A large driver code base that
worked perfectly when compiled with W2K3 SP1 DDK, could not even be compiled
with the WDK, and when workarounds to the compiler were found the execution
behavior had changed.
I can think of at least 5 developers who probably have unpleasant memories,
and don’t think it’s nonsense.
I don’t personally have the W2K3 SP1 DDK installed anymore, so it would be
difficult to generate and confirm this again. Somebody with access to the
Microsoft bug database, might tell us if OS bug 2014888 was ever fixed.
Jan
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-382068-
xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, September 23, 2009 10:05 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] static driver verifier
Jan Bottorff wrote:
> It actually can be very difficult to move from the W2K3 SP1 DDK to
the vista
> or later WDK’s. There were some changes in the behavior of signedness
of
> pointers and some bugs introduced in __ptr64.
This is complete BS. The pointer signedness did not change. It’s
always been that way. It only came to be known because people started
worrying more about 64-bit pointers.
I found the transition from the 3790 DDK to the 6000 WDK to be
essentially painless in terms of code changes.
> The link
> http://blogs.msdn.com/texblog/archive/2005/10/31/487436.aspx gives
more info
> on the pointer signed issue, which can introduce subtle bugs. I know
about
> 18 months ago, me and another developer each spent about 3 weeks
trying to
> move 300k lines of DDK built source to the Vista WDK, without
successfully
> producing stable drivers.
I find it impossible to believe that you actually found a bug in the
wild that could be explained by the pointer signedness issue. If you
have a real-world example, I challenge you to post it here.
> At this point, if it’s a product you expect to
> support on W2K8/Win7/Vista, not being on the WDK is not really an
option,
> especially if you expect to get WHQL certified.
>
This is unadulterated nonsense.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer