MSVS Lifehacks, Part 1 - Debugger. Step management
Many of us use the Visual Studio 2010 debugger, however, I can argue that most are not aware that it has additional undocumented settings that facilitate the debugging process.
In this article I will tell you how to get rid of the constant getting inside the library code during step-by-step execution. This is for priming. Later I will describe the mechanism for managing the presentation of types in debug windows like locals and watch (did everyone see how beautifully vectors / maps are displayed there, etc.?).
Please note that the main focus will be on debugging Native code.
')
And so, let's get started.
If you have already switched to C ++ 11, then you should be familiar with lines of code like the following:
At least I see these things when debugging quite often. And that's what infuriates: you stand on such a call, you want to press F11 and get into do_something, but no! at first we get inside all these std :: move and std :: forward and only then where we wanted.
Take at least the second example (with three calls to std :: forward).
To get inside do_something you have to press F10, F10, F10, F11. This is the fastest way. Only no one uses it: it is easy to make a mistake with the number of F10 and “go through” the desired call. Therefore, we press Step In, Step Out until we get to the right place. It turns out F11, Shift-F11, F11, Shift-F11, F11, Shift-F11, F11 - some kind of horror! And even so, personally, I regularly miss the right call.
And once I got tired of it. How good it would be if Step In ignored some functions, at least move and forward (which I didn't see in them?), I thought. And he began to look.
It quickly became clear that there is such an option for .NET - “Just my code”, “Step over properties and operators”, “Enable .NET framework source stepping”, and it can even be manually configured through attributes . For native code, there are no such parameters ... or is it?
It turned out that there is still. In the registry, informal.
We will be interested in the branch:
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ VisualStudio \ 10.0 \ NativeDE \ StepOver - for x86
HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ VisualStudio \ 10.0 \ NativeDE \ StepOver - for x64
This thread contains parameters of the “string” type, the name of which does not play any role, but the value determines the behavior of the debugger.
The syntax is as follows:
"= NoStepInto" means that the debugger should never go inside the specified function. You can safely omit the "= NoStepInto", because this is the default behavior, and I don’t know any other “instructions” to the debugger.
The regular expression syntax is the same as in the search , plus the following commands:
Do not log into std :: forward:
Hallelujah! Having edited the registry, we will never again get into std :: forward! Now when you press F11, we immediately go where we wanted: inside our code.
Suppose we want not to get inside the stl at all and, at the same time, boost. Easy! Let's add the corresponding lines to the registry ... But what to do if you want so that when you press F11 on this code like this:
How to make it possible to control whether we want to get into the function at the source code level when debugging (in C # this is done through attributes)?
Read in the next series.
In this article I will tell you how to get rid of the constant getting inside the library code during step-by-step execution. This is for priming. Later I will describe the mechanism for managing the presentation of types in debug windows like locals and watch (did everyone see how beautifully vectors / maps are displayed there, etc.?).
Please note that the main focus will be on debugging Native code.
')
And so, let's get started.
If you have already switched to C ++ 11, then you should be familiar with lines of code like the following:
do_something ( std :: move ( some_obj ) ) ;Well, or such:
do_something ( std :: forward < T1 > ( rr1 ) , std :: forward < T2 > ( rr2 ) , std :: forward < T3 > ( rr3 ) ) ;
At least I see these things when debugging quite often. And that's what infuriates: you stand on such a call, you want to press F11 and get into do_something, but no! at first we get inside all these std :: move and std :: forward and only then where we wanted.
Take at least the second example (with three calls to std :: forward).
To get inside do_something you have to press F10, F10, F10, F11. This is the fastest way. Only no one uses it: it is easy to make a mistake with the number of F10 and “go through” the desired call. Therefore, we press Step In, Step Out until we get to the right place. It turns out F11, Shift-F11, F11, Shift-F11, F11, Shift-F11, F11 - some kind of horror! And even so, personally, I regularly miss the right call.
And once I got tired of it. How good it would be if Step In ignored some functions, at least move and forward (which I didn't see in them?), I thought. And he began to look.
It quickly became clear that there is such an option for .NET - “Just my code”, “Step over properties and operators”, “Enable .NET framework source stepping”, and it can even be manually configured through attributes . For native code, there are no such parameters ... or is it?
It turned out that there is still. In the registry, informal.
Step-by-step execution: undocumented functions of the debugger of native code.
We will be interested in the branch:
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ VisualStudio \ 10.0 \ NativeDE \ StepOver - for x86
HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ VisualStudio \ 10.0 \ NativeDE \ StepOver - for x64
This thread contains parameters of the “string” type, the name of which does not play any role, but the value determines the behavior of the debugger.
The syntax is as follows:
<regular expression corresponding to the function name> [= NoStepInto]
"= NoStepInto" means that the debugger should never go inside the specified function. You can safely omit the "= NoStepInto", because this is the default behavior, and I don’t know any other “instructions” to the debugger.
The regular expression syntax is the same as in the search , plus the following commands:
"cid:" - C / C ++ identifier name
"funct:" - Name of the C / C ++ function (it seems to be the same as cid :)
"scope:" - set of class / space identifiers
function names (for example, ATL :: CFoo :: CBar: :)
"scope:" cannot match the empty string
"anything:" - Any string, incl. and without quotes
"oper:" - C ++ operator (for example, "*")
Examples:
Do not log into std :: forward:
std \: \: forward \ <. * \>Do not enter std :: move:
std \: \: move \ <. * \>Do not enter the namespace “test” functions:
test \: \: funct \:Do not enter overloaded operators:
\ scope: operator \ oper:
Additional Notes:
- Visual Studio reads the settings at startup, so in order for them to take effect, the studio will have to be restarted.
- If you really want to get into a function that has already been entered into the registry, this can be done either by setting a breakpoint inside it, or by making a Step In in the disassembly window.
Conclusion:
Hallelujah! Having edited the registry, we will never again get into std :: forward! Now when you press F11, we immediately go where we wanted: inside our code.
A spoon of tar.
Suppose we want not to get inside the stl at all and, at the same time, boost. Easy! Let's add the corresponding lines to the registry ... But what to do if you want so that when you press F11 on this code like this:
std :: sort ( vec. begin ( ) , vec. end ( ) , my_pred ( ) ) ;did we get inside my_pred :: operator () if it gets called?
How to make it possible to control whether we want to get into the function at the source code level when debugging (in C # this is done through attributes)?
Read in the next series.
Source: https://habr.com/ru/post/147655/
All Articles