-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proc: expose breakpoint hitcounts in expressions #3874
base: master
Are you sure you want to change the base?
Conversation
@@ -119,6 +119,7 @@ Delve defines two special variables: | |||
|
|||
* `runtime.curg` evaluates to the 'g' struct for the current goroutine, in particular `runtime.curg.goid` is the goroutine id of the current goroutine. | |||
* `runtime.frameoff` is the offset of the frame's base address from the bottom of the stack. | |||
* `runtime.bphitcount[X]` is the total hitcount for breakpoint X, which can be either an ID or the breakpoint name as a string. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more for discussion, but I'm not crazy about this going into the runtime
pseudo package we create for these special variables. It makes sense for the other two, as they are more related to the Go runtime (especially runtime.curg
) however bphitcount
is an internal (to Delve) related variable, so it seems odd to lump them together. Then again, is it worth users having to remember another pseudo package prefix?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have something in mind? Should we call it delve.bphitcount
? I don't have a strong opinion about this.
pkg/proc/eval.go
Outdated
@@ -2064,6 +2067,33 @@ func (scope *EvalScope) evalIndex(op *evalop.Index, stack *evalStack) { | |||
return | |||
} | |||
|
|||
if xev.Name == "runtime."+evalop.BreakpointHitCountVarName { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do this construction of runtime.bphitcount
repeatedly, perhaps we just have a constant for the fully qualified name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Expose breakpoint hitcounts in the expression language through the special variable runtime.bphitcount: runtime.bphitcount[1] runtime.bphitcount["bpname"] will evaluate respectively to the hitcount of breakpoint with id == 1 and to the hitcount of the breakpoint named "bpname". This is intended to be used in breakpoint conditions and allows breakpoints to be chained such that one breakpoint is only hit after a different is hit first. A few optimizations are implemented so that chained breakpoints are evaluated efficiently.
Expose breakpoint hitcounts in the expression language through the
special variable runtime.bphitcount:
runtime.bphitcount[1]
runtime.bphitcount["bpname"]
will evaluate respectively to the hitcount of breakpoint with id == 1
and to the hitcount of the breakpoint named "bpname".
This is intended to be used in breakpoint conditions and allows
breakpoints to be chained such that one breakpoint is only hit after a
different is hit first.
A few optimizations are implemented so that chained breakpoints are
evaluated efficiently.