WDK compiler bug handling __ptr64 attribute

NTDEV
1

Hi,

I’ve been trying to compile a large set of driver code (the Infiniband
protocol and hardware drivers) using the 6000/6001 WDK and get a fatal
compiler exit when doing 32-bit checked builds. The same set of code builds
on the W2K3 SP1 32-bit compiler just fine, so it’s definitely a new bug in
the WDK compiler. It also is ok on the 32-bit free build and the amd64
builds.

I’ve isolated the problem down to the simple example of driver code below.
It basically looks like the __ptr64 attribute breaks the compiler if applied
to a function pointer in a structure. Using __ptr64 is desirable because it
causes the shape/offsets of structures to be the same between 32-bit and
64-bit code.

Has anybody else seen this? I’ve already searched MSDN and Google for
“__ptr64 c1001” and found no matches. It would be real nice if some
Microsoft folks could look at this and suggest a solution. I’ve already
looked into removing all the __ptr64’s, but believe it would take some real
work to change the sources and figure out the impact (the Infiniband stack
is about 250,000 line of code).

We use Infiniband as the communication fabric for our server I/O
virtualization product, and would like to shift to the 6001 WDK toolset for
everything.

Thanks.

Jan Bottorff

Windows Systems Architect

Xsigo Systems

xxxxx@xsigo.com

#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;

}</ntddk.h>

2

Try a union with a __ptr PVOID

struct {
union {
??? void (* funcPtr)(long val);
PVOID __ptr64 dummy;
{;
} *var1;

OTOH, unless the structure is going across the wire or between UM / KM (which I am guessing it would not since it has function pointers), why does the size difference matter? The changes should be OS relative and affect a 32/64 bit boundary on the same machine

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Tuesday, February 06, 2007 1:23 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WDK compiler bug handling __ptr64 attribute

Hi,

I’ve been trying to compile a large set of driver code (the Infiniband protocol and hardware drivers) using the 6000/6001 WDK and get a fatal compiler exit when doing 32-bit checked builds. The same set of code builds on the W2K3 SP1 32-bit compiler just fine, so it’s definitely a new bug in the WDK compiler. It also is ok on the 32-bit free build and the amd64 builds.

I’ve isolated the problem down to the simple example of driver code below. It basically looks like the __ptr64 attribute breaks the compiler if applied to a function pointer in a structure. Using __ptr64 is desirable because it causes the shape/offsets of structures to be the same between 32-bit and 64-bit code.

Has anybody else seen this? I’ve already searched MSDN and Google for “__ptr64 c1001” and found no matches. It would be real nice if some Microsoft folks could look at this and suggest a solution. I’ve already looked into removing all the __ptr64’s, but believe it would take some real work to change the sources and figure out the impact (the Infiniband stack is about 250,000 line of code).

We use Infiniband as the communication fabric for our server I/O virtualization product, and would like to shift to the 6001 WDK toolset for everything.

Thanks.

Jan Bottorff
Windows Systems Architect
Xsigo Systems
xxxxx@xsigo.com

#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;
}

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</ntddk.h>

3

Interesting. Compiler should handle it better but the code seems suspicious to me. I’d expect at least warning when 32-bit function address is assigned to 64-bit pointer without typecast because function is different type than pointer (at 32-bit).

Have you tried to cast pointer to 32-bit when called? The desire is reasonable but more traditional way would probably bring better results without drastic code changes and necessity to test everything. I mean union; 64-bit number + 32 bit pointer at 32-bit system and 64-bit pointer one at 64-bit.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Jan Bottorff[SMTP:xxxxx@pmatrix.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, February 06, 2007 10:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WDK compiler bug handling __ptr64 attribute

Hi,

I’ve been trying to compile a large set of driver code (the Infiniband protocol and hardware drivers) using the 6000/6001 WDK and get a fatal compiler exit when doing 32-bit checked builds. The same set of code builds on the W2K3 SP1 32-bit compiler just fine, so it’s definitely a new bug in the WDK compiler. It also is ok on the 32-bit free build and the amd64 builds.

I’ve isolated the problem down to the simple example of driver code below. It basically looks like the __ptr64 attribute breaks the compiler if applied to a function pointer in a structure. Using __ptr64 is desirable because it causes the shape/offsets of structures to be the same between 32-bit and 64-bit code.

Has anybody else seen this? I’ve already searched MSDN and Google for “__ptr64 c1001” and found no matches. It would be real nice if some Microsoft folks could look at this and suggest a solution. I’ve already looked into removing all the __ptr64’s, but believe it would take some real work to change the sources and figure out the impact (the Infiniband stack is about 250,000 line of code).

We use Infiniband as the communication fabric for our server I/O virtualization product, and would like to shift to the 6001 WDK toolset for everything.

Thanks.

Jan Bottorff

Windows Systems Architect

Xsigo Systems

xxxxx@xsigo.com

#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;
>
> }
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
></ntddk.h>