Replies: 1 comment
-
|
Howdy! Indeed, looking through the docs on tracepoint packets with fresh eyes, I see that evaluating agent bytecode is not strictly required to support tracepoints. I think its totally reasonable for a basic implementation to reject / warn if it detects a If you've got a design in mind, and are willing to iterate here, I would be more than happy to work with you to land Tracepoint support in Supporting Agent Expressions is still something I'm very interested in supporting, and I'm certain that when the time comes to actively work on it, some APIs are going to need to change... but I won't let that nebulous future design work get in the way of landing a reasonable Tracepoint API in
Yes, that's be great! Lets move any subsequent talk about this feature to a new Issue (that you can spin up) which tracks Tracepoint support as a standalone feature. |
Beta Was this translation helpful? Give feedback.
-
Hi! I'm working on a project that uses gdbstub for driving a debugger, and we would like tracepoint support. The issue #40 mentioned it briefly as one of the downstream effects, but the WIP patch mostly only addressed bytecode buffer management and attaching to breakpoints. For our usecase however we don't actually want the bytecode management side in gdbstub for tracepoints at all: for technical reasons we're going to be writing our own bytecode interpreter anyways. I've been working on tracepoint support for our fork in order to support the project, and have a decent amount of the tracepoint packets being parsed and threaded through to the target implementation.
Is there interest in a contribution of "barebones" tracepoint support in an MR, which doesn't address bytecode management? Is there some overarching design idea of how it will tie into tracepoints that would necessitate rewriting it anyways? If it helps I can outline the
Tracepointstrait extension API that I've been developing to evaluate as well.Beta Was this translation helpful? Give feedback.
All reactions