I am no expert in VSCode, but I saw that since version 1.38 there is the possibility to add watchpoints (a breakpoint which breaks when a given memory area is modified, a feature that is supported by many debuggers), at least for C/C++, see here https://jaxenter.com/vs-code-1-38-161797.html and here https://github.com/microsoft/vscode/issues/58304. Now my version of VSCode is 1.48.2, and I still can't figure out how to do it, and I couldn't find a proper explanation either. If anyone can give an explanation on how to do it (or whether it is possible), for sure it will very beneficial for me and for the VSCode community.
I personally use the CodeLLDB extension for C++ debugging as I use LLDB. The way I create a variable watchpoint:
Put a regular break-point at where the variable is defined
Upon hitting the break-point, find the variable in the Variables pane, right click, and choose Break When Value Changes
Related
I am working on a huge program that employs a (custom built) micro-threading solution. It sometimes happens that I need debug a crash. During such times, it is useful to be able to switch from one micro-thread to another.
If I'm doing live debugging, I can replace all of the registers to those that came from the micro-thread context. I have written a macro to do just that, and it works really well.
The problem is that I cannot change the register values if I am doing post-mortem debugging (from a core file). In such a case, I have no way to tell GDB to change its concept of what the current frame is, as all registers are considered read-only in that case.
Is there a way to tell GDB about my custom context management?
Shachar
There's not a simple, built-in way to do this in gdb.
I think probably the simplest way would be to write a version of gdbserver that can read your core files and that presents your micro-threads to gdb as real threads. There's been at least one gdbserver out there that can read core files already, so maybe it isn't crazily hard. However, I couldn't really say for sure.
While debugging i press F11 often to step into a function. For this project i use properties everwhere which is simply a RAII wrapper that checks if i have set the variable and gives me an assert if i have not. Its been useful.
However now debugging is annoying since F11 will step into the property. Can i skip it somehow? by writing attributes, keywords or anything?
I am using VS11beta
This is quite easy to set up when you're dealing with managed code. You can manually mark the function with the DebuggerHiddenAttribute class, and even turn on built-in debugger settings like "Step over properties and operators".
Unfortunately, automatically stepping over a particular function is not supported by Visual Studio for native C++ code. (At least, it wasn't supported up until VS 2010—I haven't had enough time to play with VS 11 to see if this is something they gave us to make up for the fact that they stole all our colors.)
There is a workaround, though, documented a long while ago on Andy Pennell's blog:
How to Not Step Into Functions using the Visual C++ Debugger
Essentially, you edit the following registry key (for VS 2010):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\NativeDE\StepOver
or for 64-bit applications:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\NativeDE\StepOver
to specify a regular expression that will be matched against functions by the debugger.
For example, if you don't want the debugger to step into overloaded operators, you can use the following expression:
\scope:operator\oper:=NoStepInto
As the disclaimer in the blog post says:
This is not a documented feature. Well obviously you are reading this “documentation” right here, but what I mean is that is not guaranteed to work as it was never officially tested, not is it supported by Microsoft. Its existence in future versions or update to current versions is not guaranteed.
I know that E&C is a controversial subject and some say that it encourages a wrong approach to debugging, but still - I think we can agree that there are numerous cases when it is clearly useful - experimenting with different values of some constants, redesigning GUI parameters on-the-fly to find a good look... You name it.
My question is: Are we ever going to have E&C on GDB? I understand that it is a platform-specific feature and needs some serious cooperation with the compiler, the debugger and the OS (MSVC has this one easy as the compiler and debugger always come in one package), but... It still should be doable. I've even heard something about Apple having it implemented in their version of GCC [citation needed]. And I'd say it is indeed feasible.
Knowing all the hype about MSVC's E&C (my experience says it's the first thing MSVC users mention when asked "why not switch to Eclipse and gcc/gdb"), I'm seriously surprised that after quite some years GCC/GDB still doesn't have such feature. Are there any good reasons for that? Is someone working on it as we speak?
It is a surprisingly non-trivial amount of work, encompassing many design decisions and feature tradeoffs. Consider: you are debugging. The debugee is suspended. Its image in memory contains the object code of the source, and the binary layout of objects, the heap, the stacks. The debugger is inspecting its memory image. It has loaded debug information about the symbols, types, address mappings, pc (ip) to source correspondences. It displays the call stack, data values.
Now you want to allow a particular set of possible edits to the code and/or data, without stopping the debuggee and restarting. The simplest might be to change one line of code to another. Perhaps you recompile that file or just that function or just that line. Now you have to patch the debuggee image to execute that new line of code the next time you step over it or otherwise run through it. How does that work under the hood? What happens if the code is larger than the line of code it replaced? How does it interact with compiler optimizations? Perhaps you can only do this on a specially compiled for EnC debugging target. Perhaps you will constrain possible sites it is legal to EnC. Consider: what happens if you edit a line of code in a function suspended down in the call stack. When the code returns there does it run the original version of the function or the version with your line changed? If the original version, where does that source come from?
Can you add or remove locals? What does that do to the call stack of suspended frames? Of the current function?
Can you change function signatures? Add fields to / remove fields from objects? What about existing instances? What about pending destructors or finalizers? Etc.
There are many, many functionality details to attend to to make any kind of usuable EnC work. Then there are many cross-tools integration issues necessary to provide the infrastructure to power EnC. In particular, it helps to have some kind of repository of debug information that can make available the before- and after-edit debug information and object code to the debugger. For C++, the incrementally updatable debug information in PDBs helps. Incremental linking may help too.
Looking from the MS ecosystem over into the GCC ecosystem, it is easy to imagine the complexity and integration issues across GDB/GCC/binutils, the myriad of targets, some needed EnC specific target abstractions, and the "nice to have but inessential" nature of EnC, are why it has not appeared yet in GDB/GCC.
Happy hacking!
(p.s. It is instructive and inspiring to look at what the Smalltalk-80 interactive programming environment could do. In St80 there was no concept of "restart" -- the image and its object memory were always live, if you edited any aspect of a class you still had to keep running. In such environments object versioning was not a hypothetical.)
I'm not familiar with MSVC's E&C, but GDB has some of the things you've mentioned:
http://sourceware.org/gdb/current/onlinedocs/gdb/Altering.html#Altering
17. Altering Execution
Once you think you have found an error in your program, you might want to find out for certain whether correcting the apparent error would lead to correct results in the rest of the run. You can find the answer by experiment, using the gdb features for altering execution of the program.
For example, you can store new values into variables or memory locations, give your program a signal, restart it at a different address, or even return prematurely from a function.
Assignment: Assignment to variables
Jumping: Continuing at a different address
Signaling: Giving your program a signal
Returning: Returning from a function
Calling: Calling your program's functions
Patching: Patching your program
Compiling and Injecting Code: Compiling and injecting code in GDB
This is a pretty good reference to the old Apple implementation of "fix and continue". It also references other working implementations.
http://sources.redhat.com/ml/gdb/2003-06/msg00500.html
Here is a snippet:
Fix and continue is a feature implemented by many other debuggers,
which we added to our gdb for this release. Sun Workshop, SGI ProDev
WorkShop, Microsoft's Visual Studio, HP's wdb, and Sun's Hotspot Java
VM all provide this feature in one way or another. I based our
implementation on the HP wdb Fix and Continue feature, which they
added a few years back. Although my final implementation follows the
general outlines of the approach they took, there is almost no shared
code between them. Some of this is because of the architectual
differences (both the processor and the ABI), but even more of it is
due to implementation design differences.
Note that this capability may have been removed in a later version of their toolchain.
UPDATE: Dec-21-2012
There is a GDB Roadmap PDF presentation that includes a slide describing "Fix and Continue" among other bullet points. The presentation is dated July-9-2012 so maybe there is hope to have this added at some point. The presentation was part of the GNU Tools Cauldron 2012.
Also, I get it that adding E&C to GDB or anywhere in Linux land is a tough chore with all the different components.
But I don't see E&C as controversial. I remember using it in VB5 and VB6 and it was probably there before that. Also it's been in Office VBA since way back. And it's been in Visual Studio since VS2005. VS2003 was the only one that didn't have it and I remember devs howling about it. They intended to add it back anyway and they did with VS2005 and it's been there since. It works with C#, VB, and also C and C++. It's been in MS core tools for 20+ years, almost continuous (counting VB when it was standalone), and subtracting VS2003. But you could still say they had it in Office VBA during the VS2003 period ;)
And Jetbrains recently added it too their C# tool Rider. They bragged about it (rightly so imo) in their Rider blog.
I can detect when a variable changes, but it changes so often that its no use - what I want is to detect the moment that a variable becomes zero.
Thanks,
That's not possible in Visual Studio. Visual Studio supports a number of debugging features in that particular area but I don't think you can combine them into a feature to get what you want
Data Changing Breakpoints: break when a value changes (only supported in native C++)
Conditionally breakpoints: break when the IP crosses the breakpoint and a particular condition is satisfied.
What you could do though is wrap all writes to your variable into a setter function. Then use a conditional breakpoint to break when the value changes to 0. I think this is the closest you're going to get to the feature you want.
You have to use one of these debuggers
1 - http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
2 - The Good Old SoftICE, if you can find it anywhere
3 - http://www.sysersoft.com/updatelog.html
Also check new version OllyDbg (it says it supports hardware breakpoints)
I'm using the Intel compiler and visual studio and I can't seem to debug values that are in maps. I get a quick preview which shows the size of the map but the elements only show up as "(error)", I'll illustrate with a quick example, i've generated a map with a single entry myMapVariable[6]=1;
if I mouse over I get this "myMapVariable 1"
and in the watch window I get the same thing and expanding on the plus gives a single child entry which says name = "(error)" and value = 0 (which is wrong).
I've added a line to my autoexp.dat debugging file which shows the raw member variables under the child called [raw members]. I've pretty much reached the limits of my ability to dig into this further without help so I would ask if anyone here can provide some insights.
You're most likely using aggressive optimization settings. At least your screenshot is typical of that sort of thing. In that case, the debugger is actively stuffing hot values into registers, and it may be that, at the point you're stopped, the values that are needed to properly visualize the entire map are already discarded and overwritten by something else that is enough (like, say, a pointer to a current node). I would imagine that Intel C++, which is well-known for its high-quality optimization, does this sort of thing even more often than VC++ (but I've seen such with the latter often enough as well).
Consider recompiling the project in Debug configuration (which would disable the optimizer), and see if that helps.
My only suggestion is to make sure the map is initialized and in scope. Otherwise, I'm not sure, I've never seen this but I use VS2008 now.
I have never been able to fix this problem using Intel, but I have now moved to the latest visual studio compiler VS2010 and this is no longer a problem. I'm marking this as the answer because I don't want to leave unanswered questions lying around.