Nate,
I am pretty sure that I am right about the #pragma being required, or you
would have heard far more hue and cry about this. There just aren’t that
many drivers shipping with completely defective Free builds. Several of the
Rtl functions like RtlZeroMemory are macros that call memset, so if this was
really a problem, a lot of people would have found it a long time ago.
Since my problem is solved, but yours may not be, maybe you could test it?
I would do all of the following in a separate function that I called in
DriverEntry before I did anything else. Allocate some memory (you can use a
local for this), manually set the contents to something recognizable, then
use memset to make it something different. Compile it without /Oi, and
without a #pragma, and step into the memset. Is it really a function call,
or is it inlined? Check the results, did the contents of the memory change
as you expected? Then compile with /Oi, and do the same thing. Has
anything changed? Then define memset in the #pragma, (“#pragma
intrinsic(memset)”, to be precise) just before the definition of the
function where you are doing your test. Just in case you are using memset
somewhere else, add a “#pragma function(memset)” just after the definition
of this function. Now compile and step into the memset. Has it changed?
Has the resulting values in the memory changed? Now, with the #pragmas
still set, compile without the /Oi. Step into the memset. What’s
different?
Please report your findings.
Phil
-----Original Message-----
From: Nate Bushman [mailto:xxxxx@Legato.com]
Sent: Friday, March 02, 2001 10:03 AM
To: NT Developers Interest List
Subject: [ntdev] Re: AAAAAHHHH!! Locals getting trampled (windbg prob
lem?)
Does anyone know if it’s true that functions will ONLY be intrinsic
(inlined) if you use “#pragma intrinsic” to explicitly specify that you want
them to be so?
If you have a call to memcpy and you don’t use #pragma intrinsic to specify
that you want the code to be included intrinsically, is the call inlined by
default or not? And in relation to Phil’s posting (below), if you use
functions that can be intrinsic (those listed in the MSDN help under “/Oi
compiler option”), are your free driver builds safe (without the /Oi flag)
as long as you don’t explicitly specify that you want those functions build
intrinsically?
This is a huge issue. I can’t believe this is the first time I’ve heard
about it. Basically what I’m hearing is that, “If you use memcpy, strcpy,
strlen, strcmp, or any other function that can be intrinsic, the actual code
to use these functions is omitted from your free build if you don’t
explicitly set MSC_OPTIMIZATION=/Oi YOUR FREE BUILD WILL BE TOTALLY
HOSED!!!” What I’m not sure about here is if this problem occurs when
you’re using these functions without using #pragma intrinsic.
-----Original Message-----
From: Barila, Phil [mailto:xxxxx@intel.com]
Sent: Thursday, March 01, 2001 5:59 PM
To: NT Developers Interest List
Subject: [ntdev] Re: AAAAAHHHH!! Locals getting trampled (windbg prob
lem?)
/Oi is an optimization. If you specify /Od without it, you will get
absolutely no optimization. Not sure why MS defined /Oi in the Checked
build, but not the Free build, unless they were intending that the default
optimization in the Free build favor code size over speed. If I am reading
the MSDN library entry correctly, you only get intrinsics that you define in
the #pragma, so if you /Oi, but don’t define the intrinsic, you don’t get
the inlined instructions. So the effect is the same as /Od only. Anyone
know if I read the doc right?
Yes, *if* you use intrinsics, you must have /Oi, or you will build faulty
images. I discovered this by accident, when I took over development of
something that someone else had started, which used several intrinsics. If
you define the intrinsic, but don’t specify /Oi, you get confusing crashes.
You won’t get linker errors, you won’t get compile errors, just the crashes.
And yes, I think the default should be to have /Oi set in both build
environments, but I was bit quite painfully by its absence. Since it
appears that those of us who use defined intrinsics are a small minority of
DDK users, it’s probably a no-op for most people. Absolutely necessary for
those of us who need it, though.
Phil
-----Original Message-----
From: Nate Bushman [mailto:xxxxx@Legato.com]
Sent: Thursday, March 01, 2001 4:17 PM
To: NT Developers Interest List
Subject: [ntdev] Re: AAAAAHHHH!! Locals getting trampled (windbg prob
lem?)
I’m a bit confused. First, the KB article that Jay Talbott
mentions says that (if I understand this correctly) you can
turn off the default optimization in a checked build by
modifying %BASEDIR%\bin\Setenv.bat so that it does this…
set MSC_OPTIMIZATION=/Od /Oi
Why wouldn’t “set MSC_OPTIMIZATION=/Od” be sufficient? The
MSDN docs say that /Od will disable ALL optimizations. Wouldn’t
this include the /Oi optimization?
From the rest of the posts, am I right in stating that W2K free
builds will generate faulty images if you use intrinsic functions
in your code? Is the solution to this to add the following
line to your SOURCES file:
MSC_OPTIMIZATION=/Oi
Or should you edit setenv.bat to set this environment variable?
If this bug is for real, it seems that everyone should be using
/Oi for their free builds to ensure that they don’t end up building
faulty images.
You are currently subscribed to ntdev as: xxxxx@legato.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
