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.
Related
I am following the book "Beginning STM32" by Warren Gay (excellent so far, btw) which goes over how to get started with the Blue Pill.
A part that has confused me is, while we are putting our first program on our Blue Pill, the book advises to force rebuild the program before flashing it to the device. I use:
make clobber
make
make flash
My question is: Why is this necessary? Why not just flash the program since it is already made? My guess is that it is just to learn how to make an unmade program... but I also wonder if rebuilding before flashing to the device is best practice? The book does not say why?
You'd have to ask the author, but I would suggest it is "just in case" no more. Lack of trust that the make file specifies all possible dependencies perhaps. If the makefile were hand-built without automatically generated dependencies, that is entirely possible. Also it is easier to simply advise to rebuild than it is to explain all the situations where it might be necessary or otherwise, which will not be exhaustive.
From the author's point of view, it eliminates a number of possible build consistency errors that are beyond his control so it ensures you don't end up thinking the book is wrong, when it might be something you have done that the author has no control over.
Even with automatically generated dependencies, a project may have dependencies that the makefile or dependency generator does not catch, resource files used for code generation using custom tools for example.
For large projects developed over a long time, some seldom modified modules could well have been compiled with an older version of the tool chain, a clean build ensures everything is compiled and linked with the current tool.
make builds dependencies based on file timestamp; if you have build variants controlled by command-line macros, the make will not determine which dependencies are dependent on such a macro, so when building a different variant (switching from a "debug" to "release" build for example), it is good idea to rebuild all to ensure each module is consistent and compatible.
I would suggest that during a build/debug cycle you use incremental build for development speed as intended, and perform a rebuild for release or if changing some build configuration (such as enabling/disabling floating-point hardware for example or switching to a different processor variant.
If during debug you get results that seem to make no sense, such as breakpoints and code stepping not aligning with the source code, or a crash or behaviour that seems unrelated to some small change you may have made (perhaps that code has not even been executed), sometimes it may be down to a build inconsistency (for a variety of reasons usually with complex builds) and in such cases it is wise to at least eliminate build consistency as a cause by performing a rebuild all.
Certainly if you if you are releasing code to a third-party, such as a customer or for production of some product, you would probably want to perform a clean build just to ensure build consistency. You don't want users reporting bugs you cannot reproduce because the build they have been given is not reproducible.
Rebuilding the complete software is a good practice beacuse here you will generate all dependencies and symbol files path along with your local machine paths.
If you would need to debug any application with a debugger then probably you would need symbol file and paths where your source code is present and if you directly flash the application without rebuilding , then you might not be able to debug certain paths because you dont get to know at which path the application was compiled and you might miss the symbol related information.
I am trying to profile my c++ dll, but the profiler is not working with me. I would like to see the call tree an so on, but only the stl functions show up, and not all disjoint - when i click on any function, their caller is "[broken]".
I don't know if my google skills are just not sufficient, but i can not find any information on what [broken] means, and how to fix it.
This is a debug build. I cannot guarantee this is not due to some compiler settings, but i fell like i have tried everything.
It should be noted that breaking the code and adding breakpoints works fine, so the profiler just doesn't access this information
If it adds any information, profiling the specific DLL as specified here gives the exception "File contains no data buffers".
My guess is that something wrong with PDBs of your output (for instance, you may have /DEBUG:FASTLINK set in your linker's settings, which produces reference-only PDBs).
If it's not the case, you may try my profiler - it works as an extension to VisualStudio, is instrumenting (meaning it's function-accurate) and displays stats in realtime.
I have a C++ project experiencing one of those annoying problems that show up in Release but not Debug build.
So I want to create a third build configuration that is identical to Release except that it generates the PDB files (anything else?) that are needed to support step debugging and value inspection within a VS debug session when it hits an exception.
What Compiler and Linker settings do I need to change to enable this?
Once you enable optimizations, you aren't able to inspect things that are optimized away.
When you see such an entity, switching to Assembly mode with source lines alongside and looking at the processor instructions can give you hints where it went (e.g. a variable could have been moved into a register, then you can inspect the register instead).
PDB generation is enabled by default in Release configuration in VS2008. If not, the linked question lists the relevant settings.
I'm getting this strange behavior when I launch a program without selecting "Step Into new instance". It launches the program as if I had, requiring me to manually hit F5.
If I explicitly select to step into the new instance, I have to hit F5 twice before it proceeds. I've tried restarting, and messing around with the exception options. It's not an exception. And no, there isn't a breakpoint defined on the first line.
Has anyone seen this before?
I'm going to take some guesses here:
Try closing the solution then moving or renaming the *.suo file for this solution (the *.suo file keeps some information like breakpoint settings and certain UI states - it probably shouldn't be in version control if it is). Reopen the solution and see if it behaves any better.
If not, try the same process, but rename/move any *.vcxproj.user files (which have per-user project settings, and also probably shouldn't be in version control). If you're using some other project type than C++, there will be slightly different names - but I think they all end in *.user. There might also be *.vcxproj.<user name>.user files that you'd want to handle similarly.
If one of these turn out to solve the problem, you might want to look at the file to see if there's something that would tell you what the problem was (.vcxproj is quite readable XML, the *.suo file is some undocumented binary format, so you probably wouldn't be able to identify anything in there).
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.)