graal
graal copied to clipboard
Add option to exclude core files from debugger
As far as I can tell, the VS Code debugger lacks the controls to specify which files to debug. By default, we include all core library files. While that level of observability into the runtime can be very helpful at times, it can also be confusing for people looking to just debug their Ruby applications.
Consider the following simple script:
def square(x)
x * x
end
loop do
[1, 2, 3, 4].each do |i|
square(i)
end
end
When setting a breakpoint on L6 (the line that calls [1, 2, 3, 4].each), stepping over the each call steps into the loop call, loading kernel.rb automatically. I think most Rubyists would have expected to step back to the first line in the loop body, not the loop definition. I've attached a video demonstrating what this experience looks like:
https://user-images.githubusercontent.com/12584/188913132-064dce12-03ea-47fa-8629-79c16578ff0c.mp4
I think debugging both with and without stepping into the core library are valid execution modes. It would just be nice to be able to configure that in the VS Code launcher configuration.
Could you try the --core-as-internal option? That should make the debugger not look into the core library.
By default the core library is not internal because we want to list such methods in CPUSampler by default.
This is probably an issue for upstream, but I'm suggesting the VS Code extension applies that flag by default and/or exposes a new option to specify what is instrumented.
Adding "runtimeArgs": ["--experimental-options", "--core-as-internal"] to the launch configuration does not step into kernel.rb. Thanks for that.
If we can't get that changed upstream, I think it's at least worth adding it to the official docs. If this is a supported configuration, it'd be nice to remove the need for --experimental-options.
I'm not comfortable with making --core-as-internal supported, it's a hack (e.g., makes the profiler ignore core methods when using the Chrome Inspector) and in fact it already doesn't work in Native mode, since there the core library files are already loaded in the image and we can't change the internal flag after the Source is created.
I'm OK to document that in the docs until this is solved, with the caveat it only works in --jvm mode.
I think this is an issue for tooling/debugger, there should be an easy way to include/exclude different parts like:
- internal sources, excluded by default, included via
--dap.Internal/--inspect.Internal - core library sources. For the debugger it would probably make sense to not show those by default
- standard library sources
- packages/gems/libraries sources
- application sources
I think we need debugger option(s) to specify which kinds of sources we want to debug, and we need a way to specify such classification when building sources (could be an enum maybe). Could be like --dap.Sources=corelib,stdlib,packages,app or so.
It might also be useful for the user to be able to exclude a specific source paths via some globbing or so.
Hi, thank you for reporting this, we'll take a look into it and get back to you