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
Related
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.
I have the source code of an assembly language program, which has comments on every line, and I want to see those comments in the comment column of OllyDbg's disassembly as it debugs. Without writing a full blown plugin, is there any way to do this?
Comments do not make it into the final exe. I don't even think comments make it into the pdb file for a debug build.
If you have the source code that includes the comments in the directory of the exe, open the exe in olly, click the view menu then click source, this will open the source file with your comments and all.
99% of the time, what you write in your source file, is what olly shows, unless you are using a lot of macros.
After some more experience I found that there are basically 3 approaches:
Modify the .udd files that OllyDbg uses to store comments directly.
Use a label plug (unfortunately the one I found does not work on 2.01)
Create a debug file in a format OllyDbg understands (DWARF I think)
Since 3 is pretty complex, my best option is probably 1.
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.