the problem of ddk compiler.

NTFSD
1

Hi,

The DDK compiler generates the code as following when I build my fs filter with -Fc options.
I found that the local variable(bLink) has a same address of Irp, and, it can be avoided by aligns 4-bytes.
Is it a known bug of C/C++ complier? Has it another way to solve it?

_bWantCreate$ = -12
_bLink$ = 15 ================>!!!
_bIsDirectory$ = -20
_OpenFlags$ = -24
_fullPathName$ = -4
_event$ = -48
_fileEntry$ = 8
_DirID$ = -16
_ImageName$ = -68
_buffDescrptor$ = -32
_DeviceObject$ = 8
_Irp$ = 12 =================>!!!
_deviceExtension$ = -8
xxxxx@8 PROC NEAR ; COMDAT

typedef BOOLEAN BOOL;

NTSTATUS
MyFsFilterCreate(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
PDEVICE_EXTENSION deviceExtension = DeviceObject->DeviceExtension;
PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation( Irp );
PIO_STACK_LOCATION nextIrpSp = IoGetNextIrpStackLocation( Irp );
PUCHAR pOptions;
DWORD DesiredAccess;
DWORD rc;
BOOL bWantCreate = FALSE;
BOOL bWantWrite = FALSE;
BOOL bWantReturnFalse = FALSE;
BOOL bNewFile = FALSE;
BOOL bLink = FALSE;
BOOL bIsMyFile=FALSE;
BOOL OpenTargetDirectory=FALSE;
BOOL bIsDirectory=FALSE;
DWORD OpenFlags;
PCHAR fullPathName;
KEVENT event;
PMYFILE fileEntry;
DWORD DirID = 0;
CHAR ImageName[20];
NTSTATUS status;
BUFF_DESCRIPTOR buff;

…
}

Thanks in advance!
protale

2

“protale” wrote in message news:xxxxx@ntfsd…
>
> The DDK compiler generates the code as following when I build my fs
filter with -Fc options.
> I found that the local variable(bLink) has a same address of Irp, and, it
can be avoided by aligns 4-bytes.
> Is it a known bug of C/C++ complier? Has it another way to solve it?
>

There are no “known” bugs in the C compiler in the DDK, if that’s of any
help.

What version of the DDK are you using?

While it’s not really an answer to your questions, note that we use BOOLEAN
not BOOL in the drivers. BOOL (which is supposed to be a signed long value)
is typically a user-mode thing.

Peter
OSR

3

Hi, thanks for you response.

I found the really reason later - It optimizes the codes for size, and save
the IRP to register ebx in the begining,
so the address of IRP can be reused. I think that is the really reason of
the local variable(blink) has a same addrew as Irp.

Therefore, I got a new problem: Why doesn’t it use ebx to save bLink instead
of IRP? Just for curiosity.

Thanks,
protale

----- Original Message -----
From: “Peter Viscarola”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Monday, August 18, 2003 11:44 PM
Subject: [ntfsd] Re: the problem of ddk compiler.

> “protale” wrote in message news:xxxxx@ntfsd…
> >
> > The DDK compiler generates the code as following when I build my
fs
> filter with -Fc options.
> > I found that the local variable(bLink) has a same address of Irp, and,
it
> can be avoided by aligns 4-bytes.
> > Is it a known bug of C/C++ complier? Has it another way to solve it?
> >
>
> There are no “known” bugs in the C compiler in the DDK, if that’s of any
> help.
>
> What version of the DDK are you using?
>
> While it’s not really an answer to your questions, note that we use
BOOLEAN
> not BOOL in the drivers. BOOL (which is supposed to be a signed long
value)
> is typically a user-mode thing.
>
> Peter
> OSR
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@21cn.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

4

The value of the IRP address is probably used more often than the value
of blink, therefore explicitly holding it in a register is more
efficient.

The compiler is very, very smart about stack management when
optimization is turned on. Read assembly. Do not rely on debuggers to
interpret reality for you unless you have disabled optimization. It’ll
reuse stack locations whose references have passed out of scope, avoid
stack allocations for short-lived references and so forth.

Dan
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of protale
Sent: Monday, August 18, 2003 6:43 PM
To: File Systems Developers
Subject: [ntfsd] Re: the problem of ddk compiler.

Hi, thanks for you response.

I found the really reason later - It optimizes the codes for size, and
save
the IRP to register ebx in the begining,
so the address of IRP can be reused. I think that is the really reason
of
the local variable(blink) has a same addrew as Irp.

Therefore, I got a new problem: Why doesn’t it use ebx to save bLink
instead
of IRP? Just for curiosity.

Thanks,
protale

5

Oh, you are right.

Thanks.
protale.

----- Original Message -----
From: “Daniel Lovinger”
To: “File Systems Developers”
Sent: Tuesday, August 19, 2003 9:58 AM
Subject: [ntfsd] Re: the problem of ddk compiler.

The value of the IRP address is probably used more often than the value
of blink, therefore explicitly holding it in a register is more
efficient.

The compiler is very, very smart about stack management when
optimization is turned on. Read assembly. Do not rely on debuggers to
interpret reality for you unless you have disabled optimization. It’ll
reuse stack locations whose references have passed out of scope, avoid
stack allocations for short-lived references and so forth.

Dan
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of protale
Sent: Monday, August 18, 2003 6:43 PM
To: File Systems Developers
Subject: [ntfsd] Re: the problem of ddk compiler.

Hi, thanks for you response.

I found the really reason later - It optimizes the codes for size, and
save
the IRP to register ebx in the begining,
so the address of IRP can be reused. I think that is the really reason
of
the local variable(blink) has a same addrew as Irp.

Therefore, I got a new problem: Why doesn’t it use ebx to save bLink
instead
of IRP? Just for curiosity.

Thanks,
protale

—
You are currently subscribed to ntfsd as: xxxxx@21cn.com
To unsubscribe send a blank email to xxxxx@lists.osr.com