1

I'm trying to use Purify 6 to analyze a memory corruption in one of our executables built with VC++ 2003 (7.1).

When I instrument the binary with the command:

purify /Replace=yes /Run=no myprog.exe

The instrumentation aborts telling me the executable was incrementally linked. Puzzled, I checked the build options but /INCREMENTAL:NO was there. To be sure, I rebuilt it and the option was correctly passed at link time.

Is there a way to know whether an executable was incrementally linked or not ?

I had a look at what dumpbin /HEADERS says but didn't see anything relevant.

Thanks.

bltxd
  • 8,825
  • 5
  • 30
  • 44
  • I think that an incrementally-linked executable may be bigger than usual. – ChrisW Jul 07 '09 at 16:32
  • They certainly can, but knowing that does not help me. – bltxd Jul 10 '09 at 13:32
  • Are you trying the debug or release exe? Because "/INCREMENTAL is implied when /DEBUG is specified" (http://msdn.microsoft.com/en-us/library/4khtbfyf.aspx). – Kcats Jul 10 '09 at 14:30
  • If I understand correctly then LINK will not use incremental linking if no `.ilk` file is found. It will then still create a new `.ilk` file, but according to http://msdn.microsoft.com/en-us/library/4khtbfyf(VS.80).aspx that's *"in preparation for subsequent incremental linking"*, so not used for the current linking? So, what about removing all `.ilk` files and see if anything changes? And did you check the other recommended settings? Here's some for PurifyPlus: http://ibm.com/support/docview.wss?rs=995&uid=swg21265414 -- which uses **both** /DEBUG and /INCREMENTAL:NO by the way. – Arjan Jul 12 '09 at 10:23
  • @Kcats: this is a debug build, with /INCREMENTAL:NO. @Arjan: i'll try that, thanks. – bltxd Jul 15 '09 at 09:23

1 Answers1

3

Option 1:

c:...>dumpbin /summary whatever.exe

Look for a ".textbss" section.

I'm not sure this is 100% reliable, but in my experience the linker always adds this section when doing incremental linking.

Option 2:

Look for an ".ilk" file next to the executable. Visual Studio seems to be good about cleaning these up when they're not used, so disabling incremental linking and building (not even a "rebuild") should remove it.

Option 3:

Enable build logging (Tools/Options/Projects) and look for "/INCREMENTAL" or "/INCREMENTAL:NO" in the buildlog.html file that it generates.

Option 4:

Parse the .vcproj file. (ick!)

Tim Sylvester
  • 22,897
  • 2
  • 80
  • 94
  • As for cleaning up in option 2: you could be right, but the MSDN link in my comment seems to indicate otherwise. (I guess option 3 was in fact mentioned in the question itself, by validating the build command.) – Arjan Jul 14 '09 at 18:25
  • Thanks for the input. I'm gonna check point 1 right away. The other points are a bit off, since I am in control of the build process (no .vcproj here) and I just need a way to make sure a delivered binary was not incrementally linked by mistake. The build process does not install .ilk files anyway. – bltxd Jul 15 '09 at 09:22
  • If you deliver binaries somewhere best approach is to build them from clean checkout (on a dedicated build machine with controlled environment). This will eliminate this and many other potential problems. – Eugene Jul 16 '09 at 02:07
  • Looking for a .txtbss section seems to be the correct answer to my question. http://en.wikibooks.org/wiki/X86_Disassembly/Windows_Executable_Files#Code_Sections – bltxd Jul 17 '09 at 10:07