Add support for "Just My Code" debugging

[GoaLitiuM]

Visual Studio debugger supports skipping source files during Step In operations by reading the non-user code filters from *.natjmc and *.natstepfilter files under C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Packages\Debugger\Visualizers folder when Just My Code is enabled in VS settings. The debugger bundled with the VSCode extension comes with a similar folder, but there is no option to turn on the Just My Code option in the extension.

Related issues: https://github.com/microsoft/vscode-cpptools/issues/514 https://github.com/microsoft/vscode-cpptools/issues/3725

[cdacamar]

Hi,

I am a member of the Visual C++ compiler team and I use VSCode as my primary editor/debugging experience with the C++ extension. Due to the fact that our project involves a lot of std::variant visitor code, not having support for JMC is a real productivity blocker. Is there a possibility of adding priority to this feature?

[kkutsner]

It does not look like this is a priority issue which is a bummer because without JMC the debugging experience really sucks on those projects that are bigger than just simple "hello world" application.

@WardenGnaw Is this just a matter of getting more people to vote on this issue?

[BradyDonovan]

@kkutsner

Yes, that appears. @WardenGnaw mentioned this here: https://github.com/microsoft/vscode-cpptools/issues/6668#issuecomment-745494950

Please vote on #5763 by adding a 👍 to help us prioritize our features.

Anyway, I voted. I am curious to know what threshold must be met for this to be prioritized. To @kkutsner's point, debugging on any large project becomes clumsy rather quickly.

[kkutsner]

@BradyDonovan

It looks like we may need a lot of votes: https://github.com/microsoft/vscode/issues/21839 (I pasted link as a code so this issue should not reference the other issue). That issue over 700 votes and still it is not on its way...

I'm curious, this extenstion has so many user installations, but it looks like no one really uses VSCode for debugging C++ code...

[sean-mcmanus]

@kkutsner The vote count of the VS Code issue you referenced is not relevant, since it's managed by another team and they have a larger user base (all of VS Code instead of just C/C++ users). Our highest upvoted issue is https://github.com/microsoft/vscode-cpptools/issues/206 .

Lots of people use our extension for debugging C++. You can use Go to Definition and set a breakpoint in the definition you want to step into to get around the issue.

[kkutsner]

@sean-mcmanus

@kkutsner The vote count of the VS Code issue you referenced is not relevant, since it's managed by another team and they have a larger user base (all of VS Code instead of just C/C++ users). Our highest upvoted issue is #206 .

Fair point! Sorry for mentioning not quite relevant issue.

Lots of people use our extension for debugging C++. You can use Go to Definition and set a breakpoint in the definition you want to step into to get around the issue.

Yeah, that workaround may work sometimes, but such workaround is a productivity killer like @cdacamar mentioned already. Let's consider a test code below:

I need to step through lines 46 to 52 and I want to step into line 49 for every element. In VisualStudio, I only need 4+n keyboard clicks to do that, where n is the number of elements in the vector. With "Go to Definition" workaround that is a lot more, even for such artifical code example. It is because every time I need to "Step Into" I may need to do "go to definition" then put a breakpoint (or "Run to Cursor" that sets temprorary breakpoint automatically). Also, I need to put a breakpoint after the statement before doing "Step Into" in the case something goes wrong and I did the previous breakpoint on a wrong line. After all I need to cleanup any of those breakpoints...Those extra actions take additional time and patience and that is adding up quickly.

[sean-mcmanus]

For your sample code, can't you just set a breakpoint on line 49? Go to Definition isn't needed because the definition is on line 49.

I agree that doing the Go to Definition and setting the breakpoint (or doing multiple step in/outs) is annoying, although with debugging our code base I haven't found it a productivity killer enough to switch to VS debugging. I think the intent initially was for VS to be the "premier" debugging experience (paid/licensed product) so they didn't want to move too many debugging features into VS Code, but I don't know how much that reasoning applies to this particular issues versus other factors, such as team resources (I don't work on the debugger).

[kkutsner]

For your sample code, can't you just set a breakpoint on line 49? Go to Definition isn't needed because the definition is on line 49.

Yep, I can.

I think the intent initially was for VS to be the "premier" debugging experience (paid/licensed product) so they didn't want to move too many debugging features into VS Code, but I don't know how much that reasoning applies to this particular issues versus other factors, such as team resources (I don't work on the debugger).

Every dev on our team has paid VS licenses. But I found that a lot of my workflows I can do using VSCode much faster: it is keyboard centric, minimalistic, mostly runs much faster than VS....

Interestingly, that Microsoft is releasing a standalone debugger application https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-using-windbg-preview that has even more features that VS can provide as a debugging experience, for example, use JS scripting to to script the debugger - mind blowing (Something similar that GDB also can do using Python for a while)!

[kingsimba]

For your sample code, can't you just set a breakpoint on line 49? Go to Definition isn't needed because the definition is on line 49.

I agree that doing the Go to Definition and setting the breakpoint (or doing multiple step in/outs) is annoying, although with debugging our code base I haven't found it a productivity killer enough to switch to VS debugging. I think the intent initially was for VS to be the "premier" debugging experience (paid/licensed product) so they didn't want to move too many debugging features into VS Code, but I don't know how much that reasoning applies to this particular issues versus other factors, such as team resources (I don't work on the debugger).

With smart pointers use everywhere, this is definitely a productivity killer! There are trivial function calls everywhere.

std::shared_ptr<Image> image = std::make_shared<Image>(10, 20);
createNewImage(Size(image->width(), image->height())); 

Step on line 2 will go into : shared_ptr::operator->(), image::width(), shared_tr::operator->(), image::height(), Size::Size(int, int). And then into createNewImage.

With Visual Studio's *.natstepfilter. All this will not happen.

[maartennauta]

I'm wondering if I should just switch to Visual Studio proper. Since vector-of-bool is not in charge of the extension anymore it seems its not really being developed anymore. My suspicion is also that VS Code is deprioritized to get people to move to Visual Studio.

[sean-mcmanus]

@maartennauta vector-of-bool worked on the CMake Tools extension -- our team is still developing that extension. This debugging issue is not related to the CMake Tools extension. Were you hitting some other issue?

[maartennauta]

@sean-mcmanus No, my mistake probably was to assume he also worked on the cpptools extension. It seems this is the issue im also hitting (just wanting to step through my own code in the project directory when debugging C++ in VS Code, ignoring std internals and boost libraries etc) and have voted accordingly. I guess a similar request applies to "stop on exception" where I would want to only stop on all exceptions in my own code, I dont know if that is a separate issue. I have not used Just-My-Code in Visual Studio in a while so I do not know if it provides that functionality for exceptions.

[Rhahkeem]

This is absolutely necessary. When debugging and stepping in/through my code I always end up stepping into a bunch of std code. It would be great to just step through and not have worry about code other than my own when debugging an issue

[ChenLI00]

It has been two years since this problem was raised. Could it be solved in the near future.

[sean-mcmanus]

@WardenGnaw Is this feature on the debugger team backlog? Maybe those issues could be labeled with Needs more votes to help prioritize?

[WardenGnaw]

Yep. This feature work is in the backlog for the debugger.

Please react to the top post with a 👍 to vote on this feature. We will assign this issue a milestone when it's been moved off the backlog.

[akkkc]

是的。此功能工作在调试器的积压工作中。

请用👍对此功能进行投票。当此问题从积压工作中移出时，我们将为此问题分配一个里程碑。

Now there are 58 votes. I want to know how many votes are needed to remove the problem from the backlog

[sean-mcmanus]

@akkkc For comparison, https://github.com/microsoft/vscode-cpptools/issues/1201 has 86 upvotes and it's also not assigned to a milestone yet.

[fjtb1989]

its necessary,plz add it

[jepperaskdk]

This is my workaround while this feature is not enabled: GDB supports skipping files/functions and these can be predefined in e.g. ~/.gdbinit. Put e.g. this in that file (adjust versions as needed):

skip -gfi /usr/include/c++/11/bits/*.h

It will now skip all headers in that directory. See this link for more options for skips: https://sourceware.org/gdb/download/onlinedocs/gdb/Skipping-Over-Functions-and-Files.html You can directly specify files or regex for functions. Sadly, it doesn't seem like recursive globbing is supported, so I haven't been able to skip e.g. the entire /usr/include directory. https://sourceware.org/bugzilla/show_bug.cgi?id=22198

As more functions are used, you can just add more directories to be skipped.

[joelspadin-garmin]

Unfortunately, GDB won't stop on user code that's called from non-user code when using skip, so that workaround can't be used for things like skipping over the implementation of std::function() to get to the actual function call.

From piecing together info from StackOverflow, I found that this Python script works on the command line:

def stop_handler(event):
    if gdb.selected_frame().name().startswith("std::"):
        gdb.execute("step")

gdb.events.stop.connect(stop_handler)

But if I use it when debugging from VS Code, as soon as I step into any std:: function, the debugger exits with

ERROR: Error while trying to enter break state. Debugging will now stop. Failed to find thread 2 for break event

[quyykk]

Please react to the top post with a +1 to vote on this feature.

How many votes do we need? This is such a productivity killer, I'm really surprised this isn't prioritized. The workaround works for simple cases, but C++ has a ton of hidden function calls everywhere so it's really annoying.

[sean-mcmanus]

@quyykk I don't know exactly how many votes are needed, but more than 100 would help (there are 2 other debugger features with more up votes).

[ChenLI00]

我不知道确切需要多少票，但超过 100 票会有所帮助（还有 2 个其他调试器功能具有更多的赞成票）。

There are now 101 tickets available. Will this feature be added?

[jing-pei]

Is there an alternative solution?

[lowmee]

This is a practical feature, please add it

[Zingam]

Voted: +1, closing: https://github.com/microsoft/vscode-cpptools/issues/11417

[Zingam]

Debugging doesn't seem to be getting much attention. There are a few outstanding issues:

1. /JMC support on Windows
2. Debugger driver llvm-mi memory leak on macOS
3. No support for debugging as root

[cyraid]

I voted too. @WardenGnaw How many more votes are needed? It's currently at 122, seems pretty substantial at this point. :)

[tonyriviere88]

Upvoted too. This is a must have feature.

[ahcox]

Is there at least a janky sometimes-working proof of concept extension that does this to install?

[csorvagep]

If I add "justMyCode": true to the lauch.json, it shows me a warning, that justMyCode is not allowed, but it actually works with cppvsdbg. Maybe not finalized yet, since if I step into the function it does nothing, I have to press F11 many times until it skips all external calls.

[mrx23dot]

For gdb see suggested solution at the end https://github.com/microsoft/vscode-cpptools/issues/3725