'Debug' .DLL?

[ThorHammerz]

Is there a way to compile a 'Debug' .dll?

As in, the one typically "bigger" (in file size), and where you can load symbols & source code with the PDB file that comes with the build for debugging when using the 'attach to process' functionality and the 'break-all' command.

Spoiler :

Currently receiving a "No symbols are loaded for any call stack frame. The source code cannot be displayed." error.

The PDB has been properly loaded into the mod's root directory alongside the DLL.

The configuration manager only shows 'Mod' as the only build configuration, (as well as only Win32 as the solution platform... might this be the issue?), with no other options (not sure how 'creating a new configuration' works...).

Using Visual Studio 2008, on 64 bit Windows 7.

 

[whoward69]

Probably not a lot of help, but I never got the debugger to load the code by putting the .pdb file into the same directory as the .dll file (I think the dll loader within the main .exe file does something weird), but only by pointing the debugger explicitly at the .pdb file and telling it to load the symbols. I use VS-2010, and can't remember where that is off the top of my head.

The frustration with the debugger was why I wrote my own logging routines ... can't beat a good old print statement!

 

[ThorHammerz]

The frustration with the debugger was why I wrote my own logging routines ... can't beat a good old print statement!

I have my own logging routines, but they are nowhere extensive enough to cover all the stuff I need (I have a bad habit of not writing log statements until after I start running into problems)....

logging is useful only when you know what /where is causing the problems .

 

[whoward69]

Might not be related, but you haven't disabled symbol generation somehow, ie set
GenerateDebugInfo=No
under Props -> Config Props -> Linker -> Debugging

 

[S3rgeus]

If you're getting "no symbols loaded" then your problem isn't that you're running an optimized dll (although once you get debugging working, that will become a problem!). Have you already selected your mod and hit continue and are still getting "no symbols loaded"? (The game only loads your modded dll after you select your mod and proceed to the next screen - it stalls while doing this.)

I've found that leaving the pdb in the output directory of my VS project (which bears no relation to my mods folder or the CiV install directory - it's actually on a different drive to my mods folder) works fine - VS picks it up automatically.

You're not getting any "source code different" warnings, are you? (That message is surprisingly similar to the no debug symbols loaded) That would indicate that your mod is running with an older version of the dll than the code you've got.

I suppose if you're using break-all it's possible that the game might not be doing anything inside the gameplay dll that you've modified at the time. (Seems unlikely, but worth a try.) If you set a break point somewhere in your code, does it get hit? Does the breakpoint have any helpful warning text when you hover your mouse over it?



If you get debugging working and find that you want to turn optimization off, so that stepping, the watch window, and the locals window make a bit more sense, you'll need to change the option under:

Project Properties -> Configuration Properties -> C/C++ -> Optimization

Then change the "Optimization" field from "Full Optimization" to "Disabled". To make switching this easier in future, you can create a new solution configuration (I called mine ModDebug) and change the setting in that configuration. (Project properties are instanced per solution configuration - so if you create a ModDebug config and turn optimization off in there, optimization will still be on when you switch back to the Mod config.)

 

[ThorHammerz]

@S3rgeus:

I do not think it is an issue with the pdb, since I do what you do (leaving it in the output directory) and let VS pick it up.

Source code & symbols seem to load perfectly fine when I set breakpoints (e.g. the call stack and whatnots are all displayed properly), it's only when I use break-all (e.g. during an AI's turn) that no symbols can be loaded. I should note that the disassembly will still be displayed without issue.

I'll try and see what happens with the optimization part though, seems like it could be useful.

Might not be related, but you haven't disabled symbol generation somehow, ie set
GenerateDebugInfo=No
under Props -> Config Props -> Linker -> Debugging

It's currently set to "Yes /Debug"....... should it be set to no...? (doesn't this setting generate the PDB?)


---

Thanks all!

 

[S3rgeus]

@S3rgeus:

I do not think it is an issue with the pdb, since I do what you do (leaving it in the output directory) and let VS pick it up.

Source code & symbols seem to load perfectly fine when I set breakpoints (e.g. the call stack and whatnots are all displayed properly), it's only when I use break-all (e.g. during an AI's turn) that no symbols can be loaded. I should note that the disassembly will still be displayed without issue.

I'll try and see what happens with the optimization part though, seems like it could be useful.

If your breakpoints are working then your symbols are all loaded as expected for debugging the dll. When you do break-all you stop the execution of the game at wherever it happens to be at the time, which may not include any code that's a part of the dll we have source for. (Hence we have no symbols for anything else.) Try looking at the threads window (Debug -> Windows -> Threads, it's only there while attached) and switching to other threads and see if there's any of your dll code in any of the callstacks. I've generally found that breakpoints are the most precise way of stopping the game on code that we're able to reason about.

Disassembly doesn't require symbols (though doesn't show source code for reference if you don't have symbols), so that will work for the other parts of the game that aren't in our dll.

It's currently set to "Yes /Debug"....... should it be set to no...? (doesn't this setting generate the PDB?)


---

Thanks all!

It should be set to yes - as you've said, this setting generates the pdb. I think whoward just wanted you to check that it was getting generated as expected.

And no problem!

 

[ThorHammerz]

I've generally found that breakpoints are the most precise way of stopping the game on code that we're able to reason about.

Mhm. At least, when we know/suspect where the issue is ..... not much use when something during the AI's turn freezes (as in, no crashing... it just keeps going and going) and you have no idea which part of the code is going haywire .

Spoiler :

Just fixed a particularly nasty bug, as I accidentally modified the address of a pointer (rather than the value stored at the address).... somehow caused an AI's turn to continue infinitely (probably inadvertently overwrote something else that should not have been touched)