why are we still using the debug file?

(.pdb)

Beta isn't over. Simply turned off at present. I will be turned on when needed.

And the .pdb isn't debug.

<a> [/url]

> Beta isn't over. Simply turned off at present. I will be turned on when
> needed.
>
> And the .pdb isn't debug.


Sorry... Here's what a PDB is - right from the MS help files for VC++:

"By default, when the Generate Debug Info (/DEBUG) option is specified, the linker creates a program database (PDB), which holds debugging information. If Generate Debug Info (/DEBUG) is not specified, the Use Program Database (/PDB) option is ignored...."

Yup, thats a PDB file, it provides debugging information about a file, the file itself may or may not contain any debugging code.

In this case we are still curious of any crashes that may happen with the SAH application, so we still provide the bugging information on it, but the SAH application itself does not contain any debugging code.

----- Rom
BOINC Development Team, U.C. Berkeley

> Yup, thats a PDB file, it provides debugging information about a file, the
> file itself may or may not contain any debugging code.
>
> In this case we are still curious of any crashes that may happen with the SAH
> application, so we still provide the bugging information on it, but the SAH
> application itself does not contain any debugging code.

Actually, don't you mean any "application itself does not contain any debugging code, other than that generated within MS fuctions/libs/dlls when a "debug" version of a project is built"? :)

> Actually, don't you mean any "application itself does not contain any
> debugging code, other than that generated within MS fuctions/libs/dlls when a
> "debug" version of a project is built"? :)

Generally when an application is compiled it is linked against a specific set of libraries. In the case of the MS Framework libraries you get four complete sets, the dynamic debug version, static debug version, dynamic release version, and the static release version.

With our debug builds we link against the static debug libraries, with the release build we link against the static release libraries.

The release builds of the libraries and applications do not contain the debug code that generally slows down applications with extra checks.

----- Rom
BOINC Development Team, U.C. Berkeley

>
> Generally when an application is compiled it is linked against a specific set
> of libraries. In the case of the MS Framework libraries you get four complete
> sets, the dynamic debug version, static debug version, dynamic release
> version, and the static release version.
>
> With our debug builds we link against the static debug libraries, with the
> release build we link against the static release libraries.

I understand this - been using VC++ since version 1.0! (the beta, BTW)

But since there is a .pdb, it does indicate a "debug build" and per ROM, using the static libs with their own debug code! (no .pdb unless /debug!) (BTW, I'm glad you're using static libs... It does make the program "more stable" as an updated MS DLL won't break it!)

So, there is debug code being executed by the current "live" exe and dll, and it WILL have a longer execution time than a "release" build of the same modules! (this isn't a question, it's a statement, as I've seen it time and time again!)

Something I'm currently developing - the exe of the release version is 1/2 the size of the debug version, and it not that the debug code is only executed when a problem occurs! The debug code gets executed all the time to determine if a "break", "trace" or "assert" needs to happen!

Is the "debug build" also the reason that a "debug windows client" benchmarks at about 1/2 of a linux client on the same HW? (this DOES happen - trust me!)

> >
> > Generally when an application is compiled it is linked against a specific
> set
> > of libraries. In the case of the MS Framework libraries you get four
> complete
> > sets, the dynamic debug version, static debug version, dynamic release
> > version, and the static release version.
> >
> > With our debug builds we link against the static debug libraries, with
> the
> > release build we link against the static release libraries.
>
> I understand this - been using VC++ since version 1.0! (the beta, BTW)
>
> But since there is a .pdb, it does indicate a "debug build" and per ROM, using
> the static libs with their own debug code! (no .pdb unless /debug!) (BTW, I'm
> glad you're using static libs... It does make the program "more stable" as an
> updated MS DLL won't break it!)
>
> So, there is debug code being executed by the current "live" exe and dll, and
> it WILL have a longer execution time than a "release" build of the same
> modules! (this isn't a question, it's a statement, as I've seen it time and
> time again!)
>
> Something I'm currently developing - the exe of the release version is 1/2 the
> size of the debug version, and it not that the debug code is only executed
> when a problem occurs! The debug code gets executed all the time to determine
> if a "break", "trace" or "assert" needs to happen!
>
> Is the "debug build" also the reason that a "debug windows client" benchmarks
> at about 1/2 of a linux client on the same HW? (this DOES happen - trust me!)
>
By default, PDB files are not turned on for release versions. It is easy to turn them on for release builds. The debug builds were getting in Beta were much larger, and much slower than the code that we have now. The PDB files contain information that used to be in the debug executables that linked executable addresses to program statements. The only problem with using PDB files with Release builds is that the code does not line up perfectly with the source code, but it is usually pretty close.

Okay mister smarty pants, here is our additional dependencies list:
delayimp.lib gdi32.lib user32.lib kernel32.lib libcmt.lib libcpmt.lib winmm.lib opengl32.lib glu32.lib oldnames.lib ole32.lib

with the /NODEFAULTLIB option specified on the linker. Delay load options specify that the GLU32.DLL and OPENGL32.DLL libraries are delay loaded.

While the /debug flag is specified to the linker, the help for /debug on the linker states "Enables generation of debug information"

The fact that the pdb file exists doe NOT indictate that debug code is included within the executable.

Anybody can go and download the pdb files for there copy of Windows. Those files allow a developer to better debug there application, yet the OS was compiled in a release mode.

So I'll make this statement again, no debug code is being executed in the public project.

The size of the debug version of the SAH application is 1.2MB while the release build is 724KB.

----- Rom
BOINC Development Team, U.C. Berkeley

Don't anger the developer, or one morning you will find a 9999 day workunit on your client that you can't delete!

:)


<a>

> Okay mister smarty pants, here is our additional dependencies list:
> delayimp.lib gdi32.lib user32.lib kernel32.lib libcmt.lib libcpmt.lib
> winmm.lib opengl32.lib glu32.lib oldnames.lib ole32.lib

> While the /debug flag is specified to the linker, the help for /debug on the
> linker states "Enables generation of debug information"

Check your .map to see what you are really using with /debug. You might find it interesting! (not everything is static, even when you specify it!)

This might explain why the bechmark on a win client is 1/2 that of a linux client on the same HW!

Well, didn't see anything related to an assert, trace, or linking to any other library not defined already in my previous list. Basically I find no references to any thing remotely looking like functions that are included in the debug libraries.

Of course the system dll's are dynamically linked too.

If you would like, you may verify my statements as I'll go ahead and send you the MAP file.

Have you even benchmarked a client recently? Windows currently out performs the *nix platforms because gcc doesn't optimize the code the same way the MSVC compiler does.

So are you attempting to argue that the Windows debug builds are faster than the *nix release builds?

----- Rom
BOINC Development Team, U.C. Berkeley

> Well, didn't see anything related to an assert, trace, or linking to any other
> library not defined already in my previous list. Basically I find no
> references to any thing remotely looking like functions that are included in
> the debug libraries.
>
> Of course the system dll's are dynamically linked too.
>
> If you would like, you may verify my statements as I'll go ahead and send you
> the MAP file.
>
> ----- Rom
> BOINC Development Team, U.C. Berkeley
>
>
Hello Rom,

maybe you have an answer to this problem too
http://setiweb.ssl.berkeley.edu/forum_thread.php?id=1278