When stepping through my code using VSCode debugging, I see it skip lines or jump around in such a way that suggests it is jumping through optimized code. For example, it will skip lines where I have breakpoints set, even though I expect the line to be executed. Is go test running with compiler optimizations enabled? If so, is there a way to disable those optimizations? Either in the the go test command line or with VSCode settings? I tried -gcflags='-N -l' in my launch.json for a test configuration but it is not recognized.
Related
So when I am debugging my program in CLion I use F7 to see where my program travels step by step. But sometimes, the program moves into source files like "unique_ptr.h", which I am not interested in seeing. Is there a way to prevent the debugger from inspecting those files? I only want to see my own source code.
If you use LLBD just edit ~/.lldbinit. And add a line like
settings set target.process.thread.step-avoid-regexp ^(std::|boost::shared_ptr)
This prevents from stepping into std:: stuff, and also does not step into shared_ptr.
If you use GDB you can use its skipping functionality https://sourceware.org/gdb/onlinedocs/gdb/Skipping-Over-Functions-and-Files.html
In the VB6 IDE...
we can compile the project by pressing Ctrl+F5 or by choosing
File->Make Exe. Is there any difference between these two procedures?
The former one seems to be a bit faster relatively.
What I want to
know is "What's difference between these two compilation procedures (if
any...) and where should I use the first one and where should I use the
second?"
Based on this external post but added here as a question since I didn't find it on SO.
VB6 compiles "on demand" by default which is what happens when you do Run > Start (or press just F5). This means that some compile errors won't reveal themselves until they are actually called at runtime - or maybe not at all if you happen to not execute a particular block of code containing an error.
But using Ctrl-F5 or "Start with full compile" causes each and every line of code to be compiled; any potential errors can be revealed and be eliminated this way.
'Make Exe...' causes a full compile followed by writing of the EXE of your project.
You can also set some options before compiling when you use 'Make Exe...'
(such as version number).
Paraphrased from here.
I'm debugging a problem at present in Windbg from a dump. I've got the correct pdbs and I can view the locals etc quite happily. However, the source code I have (which I've pulled from the VCS branch from which this release supposedly came from) appears to be off by several lines in some parts of the stack I'm looking at. I've seen instances where it's off by 1 before, but not 3/4 lines.
What causes this? Is there any definitive way I can check that I've got the right source files?
Are you looking at debug or non optimised version of release code?
Code optimisation may cause the line shift you are seeing so you should recompile with /Od C++ optimization set to 'disabled' and see if this corrects what you see.
WinDbg uses the same method as Visual Studio to check if the source file you are viewing/setting breakpoints with matches the pdbs so it should warn you (I think it does this I cannot verify).
Besides you can verify the pdbs if not the source files using:
!itoldyouso myDLL
additionally you can open the source file in another window, during stepping and it should put a magenta line at the line it thinks the current call is at, this should be correct and behave the same as visual studio.
I've a visual C++ project I'd like to debug. However, several functions are actually generated by macro expansion ( like set##Name for a particular property). So, while debugging I can't follow the execution flow inside these generated functions.
Do I have to use the /P flag and then debug the preprocessed code?
You would have to preprocess the code using the /P flag in some other project (or on the command line, if you fancy spelling out all the include and library folders), and then compile this preprocessed code instead of the source file in your real project. Then you can debug through it.
That said, once you're at it, can't you eliminate the macros? With const, inline, and templates, I rarely ever feel the need to resort to macros, and if I do, it's usually very small, isolated pieces of code. These are either too trivial to need debugging, or I manually replace one instance of the macro with the code it generates and debug that. (However, this might have happened to me thrice in the last decade.)
I'm sort of conceptually designing a plug-in I'd love to have here. What I'd want is to be a able to tag line in my code (something like how breakpoints are added) and then get a trace log of when execution runs though them. Rather than set breakpoints (because they don't work outside the debugger), I'd rather that inside the compiler, the extra logging be added so the AST.
The main point would be to compare different runs of a program; it crashes if I do A but not if I do B and most of the code should be the same so where is it diverging?
Right now I'm doing this with file IO and a diff tool; it works but is a bit clumsy.
I guess the question is: Could this be done and has something like this been done?
I don't know of anything that exactly fits your description. However...
For debugging-only use, Visual Studio 2010 has "tracepoints". These are added in the same way as breakpoints, but rather than stopping the program, they output some text to the debug output. Because they're set in the debugger, they don't affect your source code at all.
If you want to trace activity in a release build, then just add System.Diagnostic.Trace.WriteLine() calls into your code. These can be controlled using TraceSwitches, so they can be disabled by default and only turned on if you need extra information to diagnose a problem. Unlike Debug.WriteLine() calls they are included (by default) in release builds as well as debug builds. Note that these trace calls do cost a small overhead even if the traceswitch is disabled, so avoid using them in performance critical regions of your code.