Description
Add Support for Enabling/Disabling Steeping into System Libraries
Type: Feature Request
(I would've thought this would have been an existing issue, or solved, but I haven't found anything after ~20 minutes.)
Background
Sometimes we explicitly want to step into, and set breakpoints in, either the standard library, or other installed system libraries. And at other times, this can be a nuisance that makes "step into" inconvenient to use, for example, because it steps into copy constructors, move assignment operators, whatever it may be, that are performed before the call to our own function. When undesired, the latter can disrupt our flow and be a distraction. Whilst when working on code installedin a systrem location, stepping into the former is an essential requirement.
Rough Proposed Solution
- Provide a setting, preferably in launch.json, (so that it can be enabled on a project-by-project, or configuration-by-configuration basis), to enable or disable stepping into system libraries by default.
-
When stepping into system libraries is enabled:
- Stepping into code will step into any standard library, or other system library, files/stackframes
- (Unhandled) exceptions thrown from system library code will cause the debugger to break at the thrown location in the library code
- Data breakpoints break on the nearest instruction that produces the change; be this library or user code.
-
When disabled:
- Stepping into code will ignore any system library code - except if an explicit breakpoint has been set
- (Unhandled) exceptions thrown in library code will cause the debugger to break at the first stackframe that is in user code
- Data breakpoints will ignore the location inside system libraries where the value was modified, and instead break in the first user code stackframe where the call producing the change occurred. This may be more subtle and harder to implement in an intuitive way that isn't misleading.
-
I'm not sure if data breakpoints currently work in C++ in VS Code - at least, I do not see any way to enable it on my setup, but, even if absent, I expect it wil be added in due course.
Implementation Details
- The line between system and user code isn't so trivial; so I would suggest a simple distinction that is user-changeable, based on the path of the files. On linux, anything under /lib or /usr is likely to be classed as a system library. /opt is not so clear, depengin on what we're working on. Any other paths are more likely to be user code. I would propose using a simple matching pattern to detect by default what counts as a system or user library. Any deviations from this can be managed by allowing another option in the launch JSON to specify a list of regular expressions or globs that are used to decide whether a directory is system or user. Thus, if the user is working inside a container, installing libraries in /usr/local/, actively working on system code, or has dependencies in a project, we can ignore the subtleties of this and allow the user explicitly to include the directories they want to be taken into account as of interest to them, disabling breaking on any other system libraries to ignore the rest.
- "Ignore stepping into" might be a better wording than "disable stepping into", i.e., a true rather than false boolean activates this feature.