COD listing fails for AMD64 under DDK 7600??

Greetings,

I am feeling a little dense here but I cannot get a cod listing for my 64 bit driver builds. I am using

USER_C_FLAGS=$(USER_C_FLAGS) /Fa$(O)\ /FAcs

It works fine for 32 bit builds but there is nothing for 64 bit builds. I looked in the log files and it is certainly in there.

Does the 64 bit compiler not respond to FA?

Best,

Tom

I hate to answer a question with a question… but here goes:

Why are you using the Windows 7600 DDK and not a newer version?

Peter

Tom_Udale wrote:

I am feeling a little dense here but I cannot get a cod listing for my 64 bit driver builds. I am using

USER_C_FLAGS=$(USER_C_FLAGS) /Fa$(O)\ /FAcs

It works fine for 32 bit builds but there is nothing for 64 bit builds. I looked in the log files and it is certainly in there.

Does the 64 bit compiler not respond to FA?

Greetings, Tom.  Yes, it absolutely does.  I just added your line to one
of my 7600 projects and it produced .cod files as expected.

Double-check that you have the backslash following the $O.  Without
that, the files will all get written as amd64.cod.

By the way, if you just have a one-shot need for the .cod files, the
easiest way is to use the magic CL environment variable:
    set CL=/FAsc
    build

The contents of CL are appended to every compiler command line.

Peter_Viscarola wrote:

I hate to answer a question with a question… but here goes:

Why are you using the Windows 7600 DDK and not a newer version?

I’ve worked for Tom in the past.  He has an ENORMOUS driver with a huge
legacy burden that literally dates back to the 20th Century. They have a
highly customized build environment wrapped around “build”.  Every DDK
upgrade is a huge pain in the ass for them, and the transition to Visual
Studio is going to be extra painful.  He’ll come around eventually…

I’m not sure about the DDK build environment, but our internal equivalent had an nmake target for this. So to get the assembler input for a source file named foo.c, you could type nmake.cmd foo.cod. (If your envionment doesn’t have nmake.cmd, try nmake.exe.)

Also useful: a target for the output of the preprocessor. nmake.cmd foo.pp

Hi Peter,

Tim has it right. The main issue is XP drivers. My understanding is that 7600 is the last DDK that permits you to build for XP targets (at least that is what Wikipedia tells me :). My customers are almost all academic research labs and unfortunately the upgrade from XP usually involves a number of hardware upgrades as well (mostly revolving around 3rd party devices with only 32 bit drivers) which they don’t usually have the money for after the initial system purchase, so I tend to not throw them under the bus if at all possible.

I am indeed sorely tempted by the KMDF (we are still writing directly to WDM) and building drivers in Visual Studio. But indeed I ended up writing a rather massive build environment around the DDK/DDKBUILD and VS2010 because the VS2010 batch build was so broken. So beyond coming to terms with leaving some customers behind, there is the issue of reworking the build environment for 83 separate projects, 28 of which are drivers. Sigh… we will get there of course but it is a bit of a process.

Best,

Tom

Hi Tim,

I will check out the \ and maybe try the environment variable (because indeed I was just looking at how clever the compiler was regarding array indexing via as compared to pointers). Thanks for the tips and sanity check.

Best,

Tom

My understanding is that 7600 is the last DDK that permits you to build for XP targets

That is true. However, it’s been my experience that you can use the latest WDK, set the target to Win7, and the resultant drivers will work great. Just, FYI. So you may be stuck with supporting XP systems, but you need not be saddled with an ancient build environment forever.

Now… the whole big infrastructure thing? THAT is a major thing to overcome.

Best of luck!

Peter

Hi Peter,

It is funny you should say that because as I have been messing with this FAsc business (no luck on that but no reportable results yet) I noticed that I have been doing exactly this the whole time - building for the Win7 target and installing on XP. And indeed so far no problems. What a knucklehead to a) not realize/remember that and b) not realize the implications. So I guess here I come WDK 8 or, gasp, 10 even!

Best,

Tom