Backend does not support function calls while trying to modify a string in Delve

[RezaJanalizadeh]

Please answer the following before submitting your issue:

Note: Please include any substantial examples (debug session output,
stacktraces, etc) as linked gists.

1. What version of Delve are you using (dlv version)?

Delve Debugger
Version: 1.5.1
Build: f7542d69fe14ca3d43015a19e0094d1bddd9f90e

2. What version of Go are you using? (go version)?
   go version go1.13.15 linux/arm64
3. What operating system and processor architecture are you using?
   Alpine Linux on aarch64 emulated using QEMU on x86_64 Linux Ubuntu 16.04 host which itself is installed on VirtualBox on a Mac.
4. What did you do?
   (dlv) goroutine 50 frame 1 set my_variable = "my_string"
Command failed: literal string can not be allocated because function calls are not allowed without using 'call'
   ALSO:
   (dlv) call
> main.my_function() /usr/lib/go/src/strings/strings.go:308 (hits goroutine(50):1 total:1) (PC: 0x4a929c)
Warning: debugging optimized function
Command failed: backend does not support function calls
5. What did you expect to see?
   Support for changing a string variable
6. What did you see instead?
   Quite honestly, I'm not sure since I'm not familiar with using call to modify a string in Delve (if at all possible).

[aarzilli]

This is all working as intended. Changing the value of a string requires an allocation, which can only be done by injecting a function call and function call injection is not supported on arm64 because the go runtime doesn't have an implementation for it.

[machship-mm]

Can this now be reopened due to the release of go 1.16 which supports arm64?

[tede12]

the issue persists in go version 1.16.3 on darwin/arm64

[avonar]

how can we force this issue like a community?

[aarzilli]

@avonar given the current regabi transition it's unrealistic to expect this to happen before a register ABI will exist for arm64. So, not before Go 1.18.

[Yrp]

Is anyone concerned about this issue?

[tede12]

I still have the error with go version 1.17.2 darwin/arm64

[PandyYang]

I still have the same error on the platform that go1.17.2 darwin/arm64.

[philous]

same for go1.17.3 darwin/arm64, any updates on this?

[aarzilli]

Nobody implemented it for 1.18 given the freeze likely not before 1.19.

[chenzhiguo]

I still have the same issue on the platform M1 Pro and go 1.18

[nonacosa]

+1

[mroobert]

+1

[manskx]

+1

[philous]

+1

[mmitchelljc]

+1

[EllaFoxo]

What is required of both Delve and Go on arm64 in order to implement this debugging feature? Since Delve does not support Rosetta for macOS, we're of course unable to use that with an amd64 build of Go instead.

A patch set in Go's Gerrit pages has been available for Linux for a little while, however it doesn't expand to macOS.
https://go-review.googlesource.com/c/go/+/395754/

Looking at it, the assembly portion of the change appears to be idempotent no matter the underlying kernel. My best guess is that we can adapt this change to make sure darwin/arm64 is also supported. I think the test suite should be extended with the build tag to include darwin, possibly?

I'm not sure if it's my setup, but I cherry picked the patch set and built it against the latest copy of the main branch. Delve itself reports the underlying backend still doesn't support function calls, however. So I'm guessing a change is required to Delve as well?

[AlekSi]

@aarzilli Should this issue be reopened, given that golang/go#50614 is implemented now?

[EllaFoxo]

#2996 Got merged - thanks @aarzilli! I'll run this through its paces today 😄

Edit: works like a charm. Cherry-picked the change onto the latest release and did the same for the go1.18 source change.
Added to GoLand VM options -Ddlv.path=/Users/tinyfluffs/go/bin/dlv, even better. Thanks again

[jsumners]

Reading through all of the linked issues, it's not clear to me if this is going to be supported by Delve on go1.18. It looks like go1.18.2 has the necessary support. Will there be a corresponding Delve release?

[EllaFoxo]

Reading through all of the linked issues, it's not clear to me if this is going to be supported by Delve on go1.18. It looks like go1.18.2 has the necessary support. Will there be a corresponding Delve release?

Just noticed 1.18.2 was released. Cool!

Whenever Delve does its next release, this will be there. The change was merged to the master branch in c9d800e.

If you want access earlier than that, you can compile Delve straight from the master branch as-is.

[jsumners]

Reading through all of the linked issues, it's not clear to me if this is going to be supported by Delve on go1.18. It looks like go1.18.2 has the necessary support. Will there be a corresponding Delve release?

Just noticed 1.18.2 was released. Cool!

Whenever Delve does its next release, this will be there. The change was merged to the master branch in c9d800e.

If you want access earlier than that, you can compile Delve straight from the master branch as-is.

Thank you.

[tanishgupta1]

Reading through all of the linked issues, it's not clear to me if this is going to be supported by Delve on go1.18. It looks like go1.18.2 has the necessary support. Will there be a corresponding Delve release?

Just noticed 1.18.2 was released. Cool!
Whenever Delve does its next release, this will be there. The change was merged to the master branch in c9d800e.
If you want access earlier than that, you can compile Delve straight from the master branch as-is.

Thank you.

I have installed go version 1.18.2 and delve version from the master branch but still facing the same issue in goland. Do I need to point delve in goland VM options ?

[EllaFoxo]

@tanishgupta1 Yes, try -Ddlv.path=YOUR_DELVE_LOCATION - Replacing the location with the path to the delve binary

[iholder101]

Can this be backported to earlier versions of Go?

[aarzilli]

I would have to ask the go project, not us. But the answer is likely no.

[vineetbaldwa]

I'm on go version go1.19.1 darwin/arm64 and I've installed the latest dlv under $GOPATH/bin/dlv

$ ./dlv version
Delve Debugger
Version: 1.9.1
Build: $Id: d81b9fd12bfa603f3cf7a4bc842398bd61c42940 $

I've added the VM option in goland -Ddlv.path=$GOPATH/bin/dlv to point delve to the local installation

However my application still throws an error when trying to launch in debug mode (with goland). Application error logs

[00] Starting service
[00] API server listening at: [::]:2345
[00] 2022-09-25T00:02:40Z warning layer=rpc Listening for remote connections (connections are not authenticated nor encrypted)
[00] could not launch process: fork/exec /app/testapp: function not implemented

I suspect this is due to some compatibility issue with Mac M1/ARM and go/delve. Any ideas on how to proceed further?