DDK build result different from VS result

Hi,

Due to the following post, I am trying to convert my VS.NET 2003 kernel
driver project into a VS.NET 2003 makefile project, so I can compile using
the DDK compiler, which seem safer and more supproted for kernel development.

http://msdn.microsoft.com/newsgroup...dc9074-bd6a-4e83-9c69-ea7b770c3780&sloc=en-us

I have noticed, though, that my driver becomes about twice as large (500kB
vs. 250kB) when built through the DDK compiler. What can cause this?

I am using Mark Roddy's DDKBUILD utility, and I have carefully ported all
the compiler flags from the VC project into this new makefile project.

Now, if I, in my own makefile comment out the call to

!INCLUDE $(NTMAKEENV)\makefile.def

and instead write my own makefile, like this:

!INCLUDE sources

$(TARGETNAME): $(SOURCES)
rc $(MY_RC_FLAGS) $(C_DEFINES) $(TARGETNAME).rc
cl $(USER_C_FLAGS) $(C_DEFINES) $(SOURCES) /link $(LINKER_FLAGS)
$(TARGETLIBS)
!ENDIF

the driver file now becomes about half the size, 250kB. This is also the
size I used to get through my old VS project (that was using the VS compiler).

I have compared the flags sent to 'cl' by examining the two different
buildfre_w2K_x86.log files generated by the DDK included makefile vs my own
makefile. It appears that my own makefile passes exactly the flags that I
intended, while the DDK included makefile passes an extra set of flags to the
compiler.

For instance, /G6 is passed, while I actually want /G7. So I end up with a
warning that /G7 overrides /G6. This I can take, but how about all the other
flags, can I not avoid all the "default" compiler flags and JUST use my own
flags?

Also, I noticed how 'link' is sent a whole set of flags, EVEN WHEN I add
LINKER_FLAGS=
in my sources file. Using my own makefile, I get exactly the flags I want
passed on to the linker, and the outcome is, again, the smaller 250kB rather
than 500kB.

I am trying to use maximum optimization, global optimization, and optimize
for speed, on both builds. All compiled versions of the driver seem to work,
even though I have not yet tested them for speed.

Perhaps a bunch of stuff is being stripped in one case, but not the other,
not affecting the performance of the resulting driver?

Is it expected for the 2000 FREE DDK build environment to generate larger
files, or are there more options I can configure, to make it behave just like
when I write my own makefile? I have studied the documentation for all the
build macros available to makefile and sources, and I don't see any more that
could affect my build result.


Thansk, and let me know if you need more information!

Any input appreciated,

/ Hannes.

 

USE_PDB=1

After this, the PDB file size is no more impotant to anybody

 

I'm confused. The only flags of interest with respect to
compilation/linking of your driver are in the Sources file, not in the
VC project file. That is th whole point of ddkbuild - to get your driver
built using the standard settings from the ddk. So what flags are we
talking about here?

Then you are off on your own with an unsupported build process. This
doesn't mean that your build process is wrong or faulty, it is just
unsupported.

That would be the flags that Microsoft, for good or bad, has decided are
the correct flags for compilation/linking of drivers.

So how exactly are you setting the optimization flags? Better yet, why
not just leave the flags alone and use the default settings in the ddk?

Once again you seem to have conflicted goals here. You want to use the
ddk toolset to get standard results, but you want to override all the
settings from the toolset so that you can get non-standard results. The
whole point of using the ddk toolset is to use standard tools with
standard settings so that the ouput has a reasonable chance of working
correctly, (ignoring source code defects.)

Of course there are linker flags that are immune to whatever you set
LINKER_FLAGS to. Search for LINKER_FLAGS in <ddkdir>\bin\makefile.new to
get a better understanding of what is going on here. It ain't magic.

I suggest that you strip all the crap out of your sources file, and
unless there is some real need to worry about compilation/linking size
and or speed optimizations, accept what you get.

I generally worry about compiler and linker settings right after I am
convinced that all software defects have been eliminated from the
module, and that there are no algorithmic optimizations left to
implement, which is to say I never worry about compiler and linker settings.
--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

 

I do not see any effect on the generated executable (.sys) file. Was I
supposed to?
I do, however, need the PDB file, for debugging post-release issues. This
brought no change for that one either.

/ Hannes.

 

Hi Mark,


Thanks for your comments. Let me try to clarify your questions below:

For the past three-four years, I have developed this driver entirely using a
VS project, and I have found a number of compiler and linker settings that
have a good effect on our outcome. Now that I am starting a new VS project,
this time using a VS makefile project and ddkbuild, I have made an attempt to
translate all these settings (which have taken years to refine) into settings
that now go entirely into the sources file. No more settings in VS, it's all
in the sources file now.

Ok, thanks. It's good to hear that. I was just making my own makefile to
prove that my driver *CAN* fit into 250kB. I'm still puzzled why the
supported ddk build makes it twice as big...

These are my flags, and I wish they were the ONLY flags applied:

MSC_OPTIMIZATION=/O2 /G7 /Og
USER_C_FLAGS=/nologo /Gz /GF /FD /EHsc /MT /QI0f /TP

Performance is our highest priority with this driver, so I don't wanna take
chances on weird build flags or twice as large .sys files....at least not
without understanding what the differences are.

We are running solely on Pentium 4 and Pentium M, so I certainly don't want
to optimize using /G6 (which is Pentium 1-3 compliant) - so I don't
understand why DDK enforces /G6...?

Also the size of the output file worries me. We have a stable product that
has been running for years, at 250kB. I want to understand why the file
suddenly becomes 500kB, and I am also looking for some reasasurance that it's
not gonna affect our performance.

Thanks for that point. I thought using the DDK compiler was enough to be
"supported", but if it also takes only using a subset of compiler settings
and optimizations, I realize I am much more limited. It's hard to do real
benchmarking on our product, why I am trying to optimize as far as I can
based on the documentation of compiler and linker options.

Thanks for all your input, it is highly appreciated.

/ Hannes.

 

Hi again,


Thanks for the tip from Mark Roddy of looking through the included
makefiles, to find out why certain compiler flags are added to my
compilations. I have now stripped my sources file down significantly, and I
am left with these few 'extras' in there:

TARGETNAME=spm
TARGETPATH=obj
TARGETTYPE=DRIVER

C_DEFINES=-DNDIS50_MINIPORT -DNDIS50 -DNDIS_MINIPORT_DRIVER -DNDIS_WDM=1
USER_C_FLAGS=/QI0f /TP
MSC_OPTIMIZATION=/O2 /Og
TARGETLIBS=$(DDK_LIB_DEST)\i386\ndis.lib
SOURCES=<list of my files>

Can I consider my build environment "supported" at this point, or do I need
to get rid of more flags?


Also, I am looking at some flags passed to the linker, and I am wondering if
these can cause problems to me?

-debug
-debugtype:cv
/functionpadmin:5

I want my build as optimized as possible, so seeing -debug in there worries
me a little. The documentation is not clear on whether this will generate a
less optimized driver?


And - what is /functionpadmin:5? "Minimum Function Padding" ? It seems
related to incremental linking, but the DDK also sends "INCREMENTAL:NO" to
the linker, so this seems contradictory.


Finally, I see
/pdbcompress
being passed to the linker - I assume this is not an optional flag? (yes,
the .pdb file indeed gets compressed on my file system).


Again, any input appreciated.

Thanks,

/ Hannes.


PS. The output spm.sys file is still 500kB, twice the size of the VS build
result of 250kB...