You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on a non-invasive tracing tool. Basically the idea is to never stop the debugee, as the things I'm interested in debugging are extremely timing sensitive (due to interacting with real world hardware / robotics). Basically I'm doing eBPF based tracing, but want to be able to set it from inside my IDE. DAP seems like a good way to do so.
However, it seems some key commands such as pause are required in the protocol (not gated behind a capability), even though I can't possibly support them. (And info about threads won't be displayed unless the debugee is stopped, if I read the spec correctly?)
Also, while supportsLogPoints exists, the opposite supportsNONLogPoints doesn't, which is also unfortunate, as I can only support various non-invasive actions (logging, histrograms of latency, etc).
It is a tracing tool. What is and isn't a debugger isn't really well defined. Tracing tools can be used for debugging, doesn't that make them debuggers?
Just like you wouldn't attach a pausing debugger to a process in production, but would use something like dtrace, bpftrace, systemtap etc to specify probes into the process (and system).
I want the ability to set log "break"points and probably custom types of "break"points (which seems to be supported). DAP seems to offer that without me having to write a separate plugin for vscode, neovim, etc. If I were to write separate plugins this project would never get off the ground.
I guess an option would be to return an error whenever a pause request is sent. Or just lie and pretend it is paused, in case the editor can't handle this.
Yea, erroring when pause is requested is reasonable, and you can also have the (non-log) breakpoints be unbound with an appropriate message. Would a supportsPauseRequest capability be sufficient for your case?
Yea, erroring when pause is requested is reasonable, and you can also have the (non-log) breakpoints be unbound with an appropriate message. Would a supportsPauseRequest capability be sufficient for your case?
I believe so, but I'm not far enough along the development to be able to test yet (for a while). As this is a side/hobby project it is moving along as and when I have time. I have started work on the DWARF debug info parsing logic (which is the hardest part for me, given my knowledge and experience) and the bpf generation logic (relatively easy since I'm building on top of existing libraries).
I'm working on a non-invasive tracing tool. Basically the idea is to never stop the debugee, as the things I'm interested in debugging are extremely timing sensitive (due to interacting with real world hardware / robotics). Basically I'm doing eBPF based tracing, but want to be able to set it from inside my IDE. DAP seems like a good way to do so.
However, it seems some key commands such as pause are required in the protocol (not gated behind a capability), even though I can't possibly support them. (And info about threads won't be displayed unless the debugee is stopped, if I read the spec correctly?)
Also, while supportsLogPoints exists, the opposite supportsNONLogPoints doesn't, which is also unfortunate, as I can only support various non-invasive actions (logging, histrograms of latency, etc).
It will be, right now I have not yet made it public, as I haven't really reached the point where it is useful yet. The building blocks are mostly in place. I have started on a REPL for it to it to be able to test it, and the next step after that would be DAP support. A core missing feature is still resolving addresses of local variables.
Hobby projects take time, I have too many other things going on as well.
Activity
connor4312 commentedon Sep 3, 2025
So you're trying to build a 'debugger' that can't pause execution or handle control flow? It doesn't sound like DAP is the right fit for you.
VorpalBlade commentedon Sep 3, 2025
It is a tracing tool. What is and isn't a debugger isn't really well defined. Tracing tools can be used for debugging, doesn't that make them debuggers?
Just like you wouldn't attach a pausing debugger to a process in production, but would use something like dtrace, bpftrace, systemtap etc to specify probes into the process (and system).
I want the ability to set log "break"points and probably custom types of "break"points (which seems to be supported). DAP seems to offer that without me having to write a separate plugin for vscode, neovim, etc. If I were to write separate plugins this project would never get off the ground.
I guess an option would be to return an error whenever a pause request is sent. Or just lie and pretend it is paused, in case the editor can't handle this.
connor4312 commentedon Sep 3, 2025
Yea, erroring when pause is requested is reasonable, and you can also have the (non-log) breakpoints be unbound with an appropriate message. Would a
supportsPauseRequestcapability be sufficient for your case?VorpalBlade commentedon Sep 3, 2025
I believe so, but I'm not far enough along the development to be able to test yet (for a while). As this is a side/hobby project it is moving along as and when I have time. I have started work on the DWARF debug info parsing logic (which is the hardest part for me, given my knowledge and experience) and the bpf generation logic (relatively easy since I'm building on top of existing libraries).
MicahMartin commentedon Oct 19, 2025
is this open source? would love to contribute
VorpalBlade commentedon Oct 19, 2025
It will be, right now I have not yet made it public, as I haven't really reached the point where it is useful yet. The building blocks are mostly in place. I have started on a REPL for it to it to be able to test it, and the next step after that would be DAP support. A core missing feature is still resolving addresses of local variables.
Hobby projects take time, I have too many other things going on as well.