Add ability to safely call functions #119

derekparker · 2015-05-03T16:50:32Z

Add support for calling functions within the current scope. Should allow specifying in-scope variables as arguments to these function calls.

call myFunc(localVar, 4, "foo")

The text was updated successfully, but these errors were encountered:

aarzilli · 2016-04-16T09:48:26Z

Comment moved here from PR #331:

I did think a bit about calling functions (without writing any code so this is purely philosophical) this is what I thought would be the pain points:

a. panics
b. breakpoints getting hit while evaluating a function
c. our goroutine getting scheduled out -- which makes (b) worse.

Regarding (a), one solution is to set a breakpoint on panic and abort the evaluation as soon as it is called, before it starts unwinding the stack. This is not ideal, the panic could be recovered by a frame below our dummy frame, but given how panics are generally used by go code it should be a big deal.

The other possibility would be to abort the call only when the stack unwind gets to our dummy frame, possibly modifying the g struct to slip in our own fake _defer object?

Regarding (b) and (c) I have two possible solution

Orthodox solution

For (b) we disable all user breakpoints. (c) is hard: I'm not sure it's possible to suppress co-operative scheduler calls, maybe abort on them? Even pre-emptive scheduler calls may be hard because they seem to be at least in part intertwined with stack resizes (which we can not suppress).

Unorthodox solution

We call Continue in the middle of Call, any breakpoint that gets hit is reported to the user normally, the rest of Call is executed when its temp breakpoint (which would have a condition on the goroutine id) gets hit, in a callback executed by Continue.

This is easier to implement because we don't have to worry about (b) and especially (c) but it's weird for the user.

> main.somefunction() somefile.go:10
(dlv) print a
3
(dlv) print double(a)
Command failed: function calls are not supported

The user must use a different command to enable function calls, this command will have a behaviour similar to continue and use a similar API, let's call this command exec:

(dlv) exec double(a)
> main.someotherfunction() somefile.go:50

the function call did not complete, the user got a breakpoint somewhere else in the program, the user can interact with the debugger:

(dlv) continue
> main.somefunction() somefile.go:10
    double(a) = 6
(dlv)

after another continue the original exec call completes and the user gets the evaluation result: double(a) = 6.

ignatov · 2017-07-17T20:24:45Z

@derekparker @aarzilli Do we need some changes in Go itself for this issue?

aarzilli · 2017-07-21T14:41:04Z

@ignatov: likely yes. On top of the design problems in my previous message there is also another thing to be considered. Let's say we want to initiate a call, from the debugger, to a function F from goroutine G.
We shall call the activation frame currently on top of the stack for G the "dangerframe"

We can't overwrite memory in the dangerframe because the garbage collector could run while F is executing and collect live object because we overwrote the dangerframe, so we need to add memory do G's stack (because goroutines stack are tight): how?
Let's say there was enough space on G's stack to push our arguments, space for the return value and some fake return address. Now we change RIP and restart the process to execute F. If the garbage collector runs and tries to unwind G's stack it will get hopelessly confused once it gets to the dangerframe because we made dangerframe extra fat by adding one extra arguments area at the end of it.
Even if this doesn't happen the dangerframe is not stopped at a safe point so the garbage collector wouldn't have a good pointer bitmap to determine which pointers on the dangerframe are live.

ignatov · 2017-07-21T15:31:17Z

@aarzilli maybe we should file an issue in https://github.com/golang/go/issues? We had a conversation with @rsc, and he told us that Go team is going to provide a good basement for debugger at least.

komuw · 2017-08-28T12:13:56Z

@ignatov Did you create an issue at https://github.com/golang/go/issues ?
I'm new to Go and was trying to run a func in a delve session and I came across this issue.

I'm asking, since I would like to file an issue in the Go repo, if you haven't already. Especially now that Go is collecting feedback on stuff that should go into Go2, I think a better debugging experience should be of utmost importance and having an issue open with them would greatly help.
cc @derekparker @aarzilli

ignatov · 2017-08-28T20:34:19Z

@komuw

Did you create an issue at https://github.com/golang/go/issues ?

No, I didn't. Could you please do it?

phemmer · 2017-11-08T04:08:14Z

Pardon my jumping in here, but could we side-step all the GC related issues by disabling it during the function call?
I can think of 3 risks to doing this.

function call goes nuts and consumes all memory. I think the risk here is pretty minimal, and acceptable if it gets us function calls.
function call explicitly triggers a GC. I'm not sure how delve interacts with the Go runtime, but it seems like we might be able to set a breakpoint on runtime.GC() so that we can clean up the stack, or make it a no-op.
function call re-enables the GC. Similar to # 2, set a breakpoint on debug.SetGCPercent() and no-op it.

komuw · 2018-04-05T08:38:46Z

update:
I had opened an issue on the Go issue tracker and it got a lot of traction: golang/go#21678

Additionally, there is a new proposal; golang/go#24543 that if adopted would have side benefits for debugger function calls

barely working Updates go-delve#119

This adds a mechanism for debuggers to safely inject calls to Go functions on amd64. Debuggers must participate in a protocol with the runtime, and need to know how to lay out a call frame, but the runtime support takes care of the details of handling live pointers in registers, stack growth, and detecting the trickier conditions when it is unsafe to inject a user function call. Fixes #21678. Updates derekparker/delve#119. Change-Id: I56d8ca67700f1f77e19d89e7fc92ab337b228834 Reviewed-on: https://go-review.googlesource.com/109699 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>

Implements the function call injection protocol introduced in go 1.11 by https://go-review.googlesource.com/c/go/+/109699. This is only the basic support, see TODO comments in pkg/proc/fncall.go for a list of missing features. Updates go-delve#119

Implements the function call injection protocol introduced in go 1.11 by https://go-review.googlesource.com/c/go/+/109699. This is only the basic support, see TODO comments in pkg/proc/fncall.go for a list of missing features. Updates #119

marat-rkh · 2018-10-22T17:36:02Z

I am implementing IDE integration with delve. It would be helpful to have an option to disable breakpoints while a function call is executed (as @aarzilli mentioned). Are there any plans regarding this?

The initial implementation of the 'call' command required the function call to be the root expression, i.e. something like: double(3) + 1 was not allowed, because the root expression was the binary operator '+', not the function call. With this change expressions like the one above and others are allowed. This is the first step necessary to implement nested function calls (where the result of a function call is used as argument to another function call). This is implemented by replacing proc.CallFunction with proc.EvalExpressionWithCalls. EvalExpressionWithCalls will run proc.(*EvalScope).EvalExpression in a different goroutine. This goroutine, the 'eval' goroutine, will communicate with the main goroutine of the debugger by means of two channels: continueRequest and continueCompleted. The eval goroutine evaluates the expression recursively, when a function call is encountered it takes care of setting up the function call on the target program and writes a request to the continueRequest channel, this causes the 'main' goroutine to restart the target program by calling proc.Continue. Whenever Continue encounters a breakpoint that belongs to the function call injection protocol (runtime.debugCallV1 and associated functions) it writes to continueCompleted which resumes the 'eval' goroutine. The 'eval' goroutine takes care of implementing the function call injection protocol. When the expression is fully evaluated the 'eval' goroutine will write a special message to 'continueRequest' signaling that the expression evaluation is terminated which will cause Continue to return to the user. Updates go-delve#119

Changes the code in fncall.go to support nested function calls. This changes delays argument evaluation until after we have used the call injection protocol to allocate an argument frame. When evaluating the parse tree of an expression we'll initiate each function call we find on the way down and then complete the function call on the way up. For example. in: f(g(x)) we will: 1. initiate the call injection protocol for f(...) 2. progress it until the point where we have space for the arguments of 'f' (i.e. when we receive the debugCallAXCompleteCall message from the target runtime) 3. inititate the call injection protocol for g(...) 4. progress it until the point where we have space for the arguments of 'g' 5. copy the value of x into the argument frame of 'g' 6. finish the call to g(...) 7. copy the return value of g(x) into the argument frame of 'f' 8. finish the call to f(...) Updates go-delve#119

The initial implementation of the 'call' command required the function call to be the root expression, i.e. something like: double(3) + 1 was not allowed, because the root expression was the binary operator '+', not the function call. With this change expressions like the one above and others are allowed. This is the first step necessary to implement nested function calls (where the result of a function call is used as argument to another function call). This is implemented by replacing proc.CallFunction with proc.EvalExpressionWithCalls. EvalExpressionWithCalls will run proc.(*EvalScope).EvalExpression in a different goroutine. This goroutine, the 'eval' goroutine, will communicate with the main goroutine of the debugger by means of two channels: continueRequest and continueCompleted. The eval goroutine evaluates the expression recursively, when a function call is encountered it takes care of setting up the function call on the target program and writes a request to the continueRequest channel, this causes the 'main' goroutine to restart the target program by calling proc.Continue. Whenever Continue encounters a breakpoint that belongs to the function call injection protocol (runtime.debugCallV1 and associated functions) it writes to continueCompleted which resumes the 'eval' goroutine. The 'eval' goroutine takes care of implementing the function call injection protocol. When the expression is fully evaluated the 'eval' goroutine will write a special message to 'continueRequest' signaling that the expression evaluation is terminated which will cause Continue to return to the user. Updates go-delve#119

Changes the code in fncall.go to support nested function calls. This changes delays argument evaluation until after we have used the call injection protocol to allocate an argument frame. When evaluating the parse tree of an expression we'll initiate each function call we find on the way down and then complete the function call on the way up. For example. in: f(g(x)) we will: 1. initiate the call injection protocol for f(...) 2. progress it until the point where we have space for the arguments of 'f' (i.e. when we receive the debugCallAXCompleteCall message from the target runtime) 3. inititate the call injection protocol for g(...) 4. progress it until the point where we have space for the arguments of 'g' 5. copy the value of x into the argument frame of 'g' 6. finish the call to g(...) 7. copy the return value of g(x) into the argument frame of 'f' 8. finish the call to f(...) Updates go-delve#119

coriolinus · 2019-03-07T16:15:36Z

Given that https://go-review.googlesource.com/c/go/+/109699/ is merged into go 1.12, which has been released, does there now exist a reasonable estimate when this feature will be ready?

derekparker · 2019-03-07T17:29:30Z

@coriolinus this feature is already implemented in the latest release of Delve, however it has been left open as there are still some improvements to be made.

coriolinus · 2019-03-07T17:32:20Z

That's excellent to know, thanks!

…

On Thu, Mar 7, 2019 at 6:29 PM Derek Parker ***@***.***> wrote: @coriolinus <https://github.com/coriolinus> this feature is already implemented in the latest release of Delve, however it has been left open as there are still some improvements to be made. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#119 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHdeTnM3kaO_e8ChiWlkH-OH9xiGqyHFks5vUUyFgaJpZM4EOwJX> .

The initial implementation of the 'call' command required the function call to be the root expression, i.e. something like: double(3) + 1 was not allowed, because the root expression was the binary operator '+', not the function call. With this change expressions like the one above and others are allowed. This is the first step necessary to implement nested function calls (where the result of a function call is used as argument to another function call). This is implemented by replacing proc.CallFunction with proc.EvalExpressionWithCalls. EvalExpressionWithCalls will run proc.(*EvalScope).EvalExpression in a different goroutine. This goroutine, the 'eval' goroutine, will communicate with the main goroutine of the debugger by means of two channels: continueRequest and continueCompleted. The eval goroutine evaluates the expression recursively, when a function call is encountered it takes care of setting up the function call on the target program and writes a request to the continueRequest channel, this causes the 'main' goroutine to restart the target program by calling proc.Continue. Whenever Continue encounters a breakpoint that belongs to the function call injection protocol (runtime.debugCallV1 and associated functions) it writes to continueCompleted which resumes the 'eval' goroutine. The 'eval' goroutine takes care of implementing the function call injection protocol. When the expression is fully evaluated the 'eval' goroutine will write a special message to 'continueRequest' signaling that the expression evaluation is terminated which will cause Continue to return to the user. Updates go-delve#119

Changes the code in fncall.go to support nested function calls. This changes delays argument evaluation until after we have used the call injection protocol to allocate an argument frame. When evaluating the parse tree of an expression we'll initiate each function call we find on the way down and then complete the function call on the way up. For example. in: f(g(x)) we will: 1. initiate the call injection protocol for f(...) 2. progress it until the point where we have space for the arguments of 'f' (i.e. when we receive the debugCallAXCompleteCall message from the target runtime) 3. inititate the call injection protocol for g(...) 4. progress it until the point where we have space for the arguments of 'g' 5. copy the value of x into the argument frame of 'g' 6. finish the call to g(...) 7. copy the return value of g(x) into the argument frame of 'f' 8. finish the call to f(...) Updates go-delve#119

The initial implementation of the 'call' command required the function call to be the root expression, i.e. something like: double(3) + 1 was not allowed, because the root expression was the binary operator '+', not the function call. With this change expressions like the one above and others are allowed. This is the first step necessary to implement nested function calls (where the result of a function call is used as argument to another function call). This is implemented by replacing proc.CallFunction with proc.EvalExpressionWithCalls. EvalExpressionWithCalls will run proc.(*EvalScope).EvalExpression in a different goroutine. This goroutine, the 'eval' goroutine, will communicate with the main goroutine of the debugger by means of two channels: continueRequest and continueCompleted. The eval goroutine evaluates the expression recursively, when a function call is encountered it takes care of setting up the function call on the target program and writes a request to the continueRequest channel, this causes the 'main' goroutine to restart the target program by calling proc.Continue. Whenever Continue encounters a breakpoint that belongs to the function call injection protocol (runtime.debugCallV1 and associated functions) it writes to continueCompleted which resumes the 'eval' goroutine. The 'eval' goroutine takes care of implementing the function call injection protocol. When the expression is fully evaluated the 'eval' goroutine will write a special message to 'continueRequest' signaling that the expression evaluation is terminated which will cause Continue to return to the user. Updates go-delve#119

Changes the code in fncall.go to support nested function calls. This changes delays argument evaluation until after we have used the call injection protocol to allocate an argument frame. When evaluating the parse tree of an expression we'll initiate each function call we find on the way down and then complete the function call on the way up. For example. in: f(g(x)) we will: 1. initiate the call injection protocol for f(...) 2. progress it until the point where we have space for the arguments of 'f' (i.e. when we receive the debugCallAXCompleteCall message from the target runtime) 3. inititate the call injection protocol for g(...) 4. progress it until the point where we have space for the arguments of 'g' 5. copy the value of x into the argument frame of 'g' 6. finish the call to g(...) 7. copy the return value of g(x) into the argument frame of 'f' 8. finish the call to f(...) Updates go-delve#119

The initial implementation of the 'call' command required the function call to be the root expression, i.e. something like: double(3) + 1 was not allowed, because the root expression was the binary operator '+', not the function call. With this change expressions like the one above and others are allowed. This is the first step necessary to implement nested function calls (where the result of a function call is used as argument to another function call). This is implemented by replacing proc.CallFunction with proc.EvalExpressionWithCalls. EvalExpressionWithCalls will run proc.(*EvalScope).EvalExpression in a different goroutine. This goroutine, the 'eval' goroutine, will communicate with the main goroutine of the debugger by means of two channels: continueRequest and continueCompleted. The eval goroutine evaluates the expression recursively, when a function call is encountered it takes care of setting up the function call on the target program and writes a request to the continueRequest channel, this causes the 'main' goroutine to restart the target program by calling proc.Continue. Whenever Continue encounters a breakpoint that belongs to the function call injection protocol (runtime.debugCallV1 and associated functions) it writes to continueCompleted which resumes the 'eval' goroutine. The 'eval' goroutine takes care of implementing the function call injection protocol. When the expression is fully evaluated the 'eval' goroutine will write a special message to 'continueRequest' signaling that the expression evaluation is terminated which will cause Continue to return to the user. Updates go-delve#119

The initial implementation of the 'call' command required the function call to be the root expression, i.e. something like: double(3) + 1 was not allowed, because the root expression was the binary operator '+', not the function call. With this change expressions like the one above and others are allowed. This is the first step necessary to implement nested function calls (where the result of a function call is used as argument to another function call). This is implemented by replacing proc.CallFunction with proc.EvalExpressionWithCalls. EvalExpressionWithCalls will run proc.(*EvalScope).EvalExpression in a different goroutine. This goroutine, the 'eval' goroutine, will communicate with the main goroutine of the debugger by means of two channels: continueRequest and continueCompleted. The eval goroutine evaluates the expression recursively, when a function call is encountered it takes care of setting up the function call on the target program and writes a request to the continueRequest channel, this causes the 'main' goroutine to restart the target program by calling proc.Continue. Whenever Continue encounters a breakpoint that belongs to the function call injection protocol (runtime.debugCallV1 and associated functions) it writes to continueCompleted which resumes the 'eval' goroutine. The 'eval' goroutine takes care of implementing the function call injection protocol. When the expression is fully evaluated the 'eval' goroutine will write a special message to 'continueRequest' signaling that the expression evaluation is terminated which will cause Continue to return to the user. Updates #119

Changes the code in fncall.go to support nested function calls. This changes delays argument evaluation until after we have used the call injection protocol to allocate an argument frame. When evaluating the parse tree of an expression we'll initiate each function call we find on the way down and then complete the function call on the way up. For example. in: f(g(x)) we will: 1. initiate the call injection protocol for f(...) 2. progress it until the point where we have space for the arguments of 'f' (i.e. when we receive the debugCallAXCompleteCall message from the target runtime) 3. inititate the call injection protocol for g(...) 4. progress it until the point where we have space for the arguments of 'g' 5. copy the value of x into the argument frame of 'g' 6. finish the call to g(...) 7. copy the return value of g(x) into the argument frame of 'f' 8. finish the call to f(...) Updates go-delve#119

* proc: support nested function calls Changes the code in fncall.go to support nested function calls. This changes delays argument evaluation until after we have used the call injection protocol to allocate an argument frame. When evaluating the parse tree of an expression we'll initiate each function call we find on the way down and then complete the function call on the way up. For example. in: f(g(x)) we will: 1. initiate the call injection protocol for f(...) 2. progress it until the point where we have space for the arguments of 'f' (i.e. when we receive the debugCallAXCompleteCall message from the target runtime) 3. inititate the call injection protocol for g(...) 4. progress it until the point where we have space for the arguments of 'g' 5. copy the value of x into the argument frame of 'g' 6. finish the call to g(...) 7. copy the return value of g(x) into the argument frame of 'f' 8. finish the call to f(...) Updates #119 * proc: bugfix: closure addr was wrong for non-closure functions

derekparker · 2019-05-31T16:23:01Z

Going to officially close this out as we now have this functionality. We will continue adding more improvements and @aarzilli has done a ton already.

go-delve#119) * added dev env container for webhook worker * using ContainerName * Squashed commit of the following: commit 504164e Author: Elliot <elliot@burstsms.com> Date: Thu Jan 28 16:23:29 2021 +1100 RPC infra simplification (go-delve#118) * init * mm7 port * rpcbuilder listen host * container names fix for jaeger * revert port mapping in dev * template * container_port, container_name struct fields * rpc_service -> rpc_address env vars/ struct fields * charts * trigger build rerun * struct fields * more fields and naming * removed extra blank line * de-lint * changing the webhook message queue exchange name to "webhook-post" * remove ports not required until the health check PR is created

Implements the function call injection protocol introduced in go 1.11 by https://go-review.googlesource.com/c/go/+/109699. This is only the basic support, see TODO comments in pkg/proc/fncall.go for a list of missing features. Updates go-delve#119

) The initial implementation of the 'call' command required the function call to be the root expression, i.e. something like: double(3) + 1 was not allowed, because the root expression was the binary operator '+', not the function call. With this change expressions like the one above and others are allowed. This is the first step necessary to implement nested function calls (where the result of a function call is used as argument to another function call). This is implemented by replacing proc.CallFunction with proc.EvalExpressionWithCalls. EvalExpressionWithCalls will run proc.(*EvalScope).EvalExpression in a different goroutine. This goroutine, the 'eval' goroutine, will communicate with the main goroutine of the debugger by means of two channels: continueRequest and continueCompleted. The eval goroutine evaluates the expression recursively, when a function call is encountered it takes care of setting up the function call on the target program and writes a request to the continueRequest channel, this causes the 'main' goroutine to restart the target program by calling proc.Continue. Whenever Continue encounters a breakpoint that belongs to the function call injection protocol (runtime.debugCallV1 and associated functions) it writes to continueCompleted which resumes the 'eval' goroutine. The 'eval' goroutine takes care of implementing the function call injection protocol. When the expression is fully evaluated the 'eval' goroutine will write a special message to 'continueRequest' signaling that the expression evaluation is terminated which will cause Continue to return to the user. Updates go-delve#119

* proc: support nested function calls Changes the code in fncall.go to support nested function calls. This changes delays argument evaluation until after we have used the call injection protocol to allocate an argument frame. When evaluating the parse tree of an expression we'll initiate each function call we find on the way down and then complete the function call on the way up. For example. in: f(g(x)) we will: 1. initiate the call injection protocol for f(...) 2. progress it until the point where we have space for the arguments of 'f' (i.e. when we receive the debugCallAXCompleteCall message from the target runtime) 3. inititate the call injection protocol for g(...) 4. progress it until the point where we have space for the arguments of 'g' 5. copy the value of x into the argument frame of 'g' 6. finish the call to g(...) 7. copy the return value of g(x) into the argument frame of 'f' 8. finish the call to f(...) Updates go-delve#119 * proc: bugfix: closure addr was wrong for non-closure functions

Implements the function call injection protocol introduced in go 1.11 by https://go-review.googlesource.com/c/go/+/109699. This is only the basic support, see TODO comments in pkg/proc/fncall.go for a list of missing features. Updates go-delve#119

) The initial implementation of the 'call' command required the function call to be the root expression, i.e. something like: double(3) + 1 was not allowed, because the root expression was the binary operator '+', not the function call. With this change expressions like the one above and others are allowed. This is the first step necessary to implement nested function calls (where the result of a function call is used as argument to another function call). This is implemented by replacing proc.CallFunction with proc.EvalExpressionWithCalls. EvalExpressionWithCalls will run proc.(*EvalScope).EvalExpression in a different goroutine. This goroutine, the 'eval' goroutine, will communicate with the main goroutine of the debugger by means of two channels: continueRequest and continueCompleted. The eval goroutine evaluates the expression recursively, when a function call is encountered it takes care of setting up the function call on the target program and writes a request to the continueRequest channel, this causes the 'main' goroutine to restart the target program by calling proc.Continue. Whenever Continue encounters a breakpoint that belongs to the function call injection protocol (runtime.debugCallV1 and associated functions) it writes to continueCompleted which resumes the 'eval' goroutine. The 'eval' goroutine takes care of implementing the function call injection protocol. When the expression is fully evaluated the 'eval' goroutine will write a special message to 'continueRequest' signaling that the expression evaluation is terminated which will cause Continue to return to the user. Updates go-delve#119

* proc: support nested function calls Changes the code in fncall.go to support nested function calls. This changes delays argument evaluation until after we have used the call injection protocol to allocate an argument frame. When evaluating the parse tree of an expression we'll initiate each function call we find on the way down and then complete the function call on the way up. For example. in: f(g(x)) we will: 1. initiate the call injection protocol for f(...) 2. progress it until the point where we have space for the arguments of 'f' (i.e. when we receive the debugCallAXCompleteCall message from the target runtime) 3. inititate the call injection protocol for g(...) 4. progress it until the point where we have space for the arguments of 'g' 5. copy the value of x into the argument frame of 'g' 6. finish the call to g(...) 7. copy the return value of g(x) into the argument frame of 'f' 8. finish the call to f(...) Updates go-delve#119 * proc: bugfix: closure addr was wrong for non-closure functions

derekparker added enhancement command labels May 3, 2015

derekparker added this to the 1.0 milestone May 3, 2015

derekparker mentioned this issue Oct 9, 2015

Printing an error type should print result of .Error() #60

Closed

dlsniper mentioned this issue Nov 15, 2015

Debugging not working as expected go-lang-plugin-org/go-lang-idea-plugin#1998

Closed

aarzilli mentioned this issue Jan 10, 2016

Support for evaluating expressions #251

Closed

komuw mentioned this issue Aug 29, 2017

runtime: provide a mechanism for debuggers to execute a function in the program being debugged golang/go#21678

Closed

komuw mentioned this issue Sep 6, 2017

Roadmap to 1.0 #710

Closed

dlsniper mentioned this issue Apr 24, 2018

Support debugging for tests go-lang-plugin-org/go-lang-idea-plugin#1855

Open

aarzilli added a commit to aarzilli/delve that referenced this issue May 8, 2018

! NEEDS GO CHANGE ! ! INCOMPLETE ! *: function calls

575bfc4

barely working Updates go-delve#119

aarzilli added a commit to aarzilli/delve that referenced this issue May 8, 2018

! NEEDS GO CHANGE ! ! INCOMPLETE ! *: function calls

c3cb4b1

barely working Updates go-delve#119

aarzilli added a commit to aarzilli/delve that referenced this issue May 8, 2018

! NEEDS GO CHANGE ! ! INCOMPLETE ! *: function calls

5714069

barely working Updates go-delve#119

aarzilli added a commit to aarzilli/delve that referenced this issue May 14, 2018

! NEEDS GO CHANGE ! ! INCOMPLETE ! *: function calls

59d5486

barely working Updates go-delve#119

aarzilli added a commit to aarzilli/delve that referenced this issue May 17, 2018

! NEEDS GO CHANGE ! ! INCOMPLETE ! *: function calls

3ce65ed

barely working Updates go-delve#119

aarzilli added a commit to aarzilli/delve that referenced this issue May 21, 2018

! NEEDS GO CHANGE ! ! INCOMPLETE ! *: function calls

acceaee

barely working Updates go-delve#119

derekparker closed this as completed May 31, 2019

eedwards-sk mentioned this issue Oct 8, 2019

Function calls via delve 'call' are not supported microsoft/vscode-go#2655

Closed

A-UNDERSCORE-D mentioned this issue Jan 25, 2020

Pass "dlv commands" from debug console to dlv microsoft/vscode-go#2992

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add ability to safely call functions #119

Add ability to safely call functions #119

derekparker commented May 3, 2015

aarzilli commented Apr 16, 2016

ignatov commented Jul 17, 2017

aarzilli commented Jul 21, 2017

ignatov commented Jul 21, 2017

komuw commented Aug 28, 2017 •

edited

Loading

ignatov commented Aug 28, 2017 •

edited

Loading

phemmer commented Nov 8, 2017 •

edited

Loading

komuw commented Apr 5, 2018

marat-rkh commented Oct 22, 2018

coriolinus commented Mar 7, 2019 •

edited

Loading

derekparker commented Mar 7, 2019

coriolinus commented Mar 7, 2019 via email

derekparker commented May 31, 2019

Add ability to safely call functions #119

Add ability to safely call functions #119

Comments

derekparker commented May 3, 2015

aarzilli commented Apr 16, 2016

Orthodox solution

Unorthodox solution

ignatov commented Jul 17, 2017

aarzilli commented Jul 21, 2017

ignatov commented Jul 21, 2017

komuw commented Aug 28, 2017 • edited Loading

ignatov commented Aug 28, 2017 • edited Loading

phemmer commented Nov 8, 2017 • edited Loading

komuw commented Apr 5, 2018

marat-rkh commented Oct 22, 2018

coriolinus commented Mar 7, 2019 • edited Loading

derekparker commented Mar 7, 2019

coriolinus commented Mar 7, 2019 via email

derekparker commented May 31, 2019

komuw commented Aug 28, 2017 •

edited

Loading

ignatov commented Aug 28, 2017 •

edited

Loading

phemmer commented Nov 8, 2017 •

edited

Loading

coriolinus commented Mar 7, 2019 •

edited

Loading