ARM support

[derekparker]

Add support for ARM processors.

[tylerarnold]

yes please for ARM processors. I'd love to help but my bandwidth is limited at the moment.

[ci-iotsyst]

If this helps, when compiling, I get:

src/github.com/derekparker/delve/proc/disasm.go:9: undefined: ArchInst

[dt-rush]

Can anyone familiar with the technical hurdles give a high level breakdown of what they are?

[willwp]

@dt-rush The overall technical hurdle is adding in the arm64 disassembler golang files in /pkg/proc/disasm_arm64.go. You can find my work on the forked delve repo, arm64_fix branch.
I've taken the arch/arm64 files from the golang source tree and put them in the vendor/golang.org/x/arch directory in the arm64_fix branch of delve.
The technical hurdles are as follows:

• There are still calls to the Intel instruction set that need to be converted to arm64/RISC operations in /pkg/proc/diasm_arm64.go Right now there are calls in disasm_arm64.go to CALL, LCALL, and Rel, Segment, Base, Index, and Imm that need to be ported from x86 to arm64 procedures.
• Verification and testing that arm64 conversion works.

[alanjds]

I will probable be asking too much, but ARM32 would be nice too.

[gidoBOSSftw5731]

whats the status here, is there any way people can contribute to help? I want to code on a chromebook but this makes it hard

[sethwklein]

@gidoBOSSftw5731, I suspect looking at the repository @willwp linked would be a good start. If you find you have the understanding and time necessary to contribute, you should be able to do so by making pull requests from a forked repository in the usual way.

If you find that you (like me, FWIW) don't know enough to contribute that way, then you could wait until @willwp's first bullet point is complete and work starts on the second, the testing one. At that point, assuming it arrives, you will be able to clone and build some branch of delve on your Chromebook and try it out, reporting bugs as you find them.

[christoofar]

:-(

go install "-ldflags=-X main.Build=34e802a42b9dc3ba3c4a513b50e9eec6afedcdf2" github.com/derekparker/delve/cmd/dlv
# github.com/derekparker/delve/pkg/proc
pkg/proc/disasm.go:12:14: undefined: archInst```

[christoofar]

It would be really nice to debug my go code on a Raspberry PI or on an ARM simulator locally. Sometimes I dump out before I can pinpoint where the bug is and have to cycle through a lot of slow recompiling/guesswork to spot the issue.

[uudashr]

Do we have progress on this?

[beiriannydd]

I looked at @willwp branch and it appears to be a first attempt, simply copying the amd64 code and beginning to make some changes. ARM works differently to X86. The CALL equivalents are BL and BLR which take a 26bit signed immediate and a register ID respectively. disasm seems to have some direct expectations on the attributes exposed by Instr. Len for instance is, I think, 32bits or 4 bytes at all times? Therefore it doesn't exist in the struct. Size() should in that case return 4 for everything and Size() calls should replace references to Len in Disasm. This could be confirmed by looking at the instr.json which lists either bit values or argument types and bit lengths. ARM memory doesn't have the same memory segmentation as Intel, so there is simply one 64 bit register and not a segment and offset. I wish I could dedicate time to this, it is a good cause.

[willwp]

That was my first try, and I plan on reading up on https://golang.org/doc/asm#arm64 and making it my changes correct.

…

On Sun, Dec 30, 2018 at 9:52 PM Faye Salwin ***@***.***> wrote: I looked at @willwp <https://github.com/willwp> branch and it appears to be a first attempt, simply copying the amd64 code and beginning to make some changes. ARM works differently to X86. The CALL equivalents are BL and BLR which take a 26bit signed immediate and a register ID respectively. disasm seems to have some direct expectations on the attributes exposed by Instr. Len for instance is, I think, 32bits or 4 bytes at all times? Therefore it doesn't exist in the struct. Size() should in that case return 4 for everything and Size() calls should replace references to Len in Disasm. This could be confirmed by looking at the instr.json which lists either bit values or argument types and bit lengths. ARM memory doesn't have the same memory segmentation as Intel, so there is simply one 64 bit register and not a segment and offset. I wish I could dedicate time to this, it is a good cause. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/derekparker/delve/issues/118#issuecomment-450605606>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AmsZ3_dWjOatseLva7CnBe7oiQU5JfA-ks5u-YoYgaJpZM4EOwEa> .

[mikemadden42]

I'm running into this issue on a raspberry pi 3:

$ go get -u -ldflags="-s -w" github.com/go-delve/delve/cmd/dlv
# github.com/go-delve/delve/pkg/proc
go/src/github.com/go-delve/delve/pkg/proc/disasm.go:12:14: undefined: archInst

$ go version
go version go1.12.4 linux/arm64
$ uname -a
Linux kali 4.19.29-Re4son-v8+ #6 SMP PREEMPT Wed Mar 27 00:15:50 UTC 2019 aarch64 GNU/Linux

[LaPingvino]

I use VSCode on my Arm64 Chromebook in Crostini, and the Go extension depends on delve. What would be the best way to stub it out for now so I can at least run my code from the editor?

[derekparker]

I am currently investigating porting to other arches, the first would be ARM64. That is unless someone else out there is currently making progress on this port. I have a local branch that I've been testing my changes on while I'm working.

[bus710]

Would be super nice to have Delve in any kind of small Linux box like RPi, Chromebooks, or even some Android phones/tablets!

I am sure that many of Go/Delve users would like to help Delve-ARM as tester as I am willing to.

[hengwu0]

Hi all, I'm working in ZTE. And our team have finished arm64 delve preliminary(we have done breakpoint, stack backtrace, disassembly work). I believe there are many users other than ZTE are using golang arm64 as well, and we all need delve! So, let's restart to do this well. And here is the steps:
1、filename changes(also will move some code to _amd.go file and change tiny code of course.)
2、preliminary function(breakpoint, disassembly, stack backtrace, general purpose registers), so the debugging of simple programs should be ok!(with testcases.)
3、complete floating-point instruction set(with testcases too.)
4、coredump function and other functions
5、bugfix.

I'm so grateful that you're working on this. I have been wanting to delve on an rpi for so long. There's some hardware that I can only run on ARM and debug it there. fmt.Println(stuff) only works so far :)

Now, you can debug arm64 with all delve commands except stack command(like bt, frame...). Stacktrace is start pushing.

[paralin]

@hengwu0 any chance for arm32 support?

[hengwu0]

@hengwu0 any chance for arm32 support?

Sorry, i have no idea on arm32.

[bus710]

I finally installed the ARM64 version on RPI4 that runs Ubuntu 19.04 19.10 to see how it works.

The version info seems like this after installation:

$ dlv version

Delve Debugger
Version: 1.3.2
Build: bc9d95d615987ae78b946dd18ef1989775c705e8

My tip is that, the manual installation should be done instead of go get.

• https://github.com/go-delve/delve/blob/master/Documentation/installation/linux/install.md
• Otherwise, the undefined arch error will be shown.

I will keep using the ARM version and hopefully I can fully use the power.

Thanks for @hengwu0, @derekparker and to whom put so much effort for this.

Edit: the version of Ubuntu used from 19.04 => 19.10

[vielmetti]

@bus710 what is the exact "undefined arch" error you are getting with go get?

[bus710]

@bus710 what is the exact "undefined arch" error you are getting with go get?

I will probably try to reproduce the message after work.

[aarzilli]

It's because go get will retrieve the latest tagged version by default and 1.3.x do not have ARM support, there is no need to look further into this, it will be resolved when we tag 1.4.0, which hopefully is soon after Go 1.14 is released.

[derekparker]

Closing this as we do have ARM support now, and with the latest tagged release it is go get'able.

[MattiaCostamagna]

Hi!
Do you plan to release it also for ARM32 architectures? I tried to install delve on an OrangePI Zero and I got the following error:

$ go get -v -u github.com/go-delve/delve/cmd/dlv
github.com/go-delve/delve (download)
package github.com/go-delve/delve/pkg/proc/native: found packages native (proc.go) and your_operating_system_and_architecture_combination_is_not_supported_by_delve (support_sentinel.go) in /opt/sources/gopath/src/github.com/go-delve/delve/pkg/proc/native

If I try and get the @latest version, I get the following output:

$ go get -v -u github.com/go-delve/delve/cmd/dlv@latest
# github.com/go-delve/delve/pkg/proc/native
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/proc.go:164:13: cannot use v (type *Thread) as type proc.Thread in append:
	*Thread does not implement proc.Thread (missing SetDX method)
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/proc.go:172:2: cannot use th (type *Thread) as type proc.Thread in return argument:
	*Thread does not implement proc.Thread (missing SetDX method)
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/proc.go:177:12: cannot use dbp.currentThread (type *Thread) as type proc.Thread in return argument:
	*Thread does not implement proc.Thread (missing SetDX method)
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/proc.go:265:2: cannot use trapthread (type *Thread) as type proc.Thread in return argument:
	*Thread does not implement proc.Thread (missing SetDX method)
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/proc.go:275:43: cannot use dbp.currentThread (type *Thread) as type proc.Thread in argument to proc.GetG:
	*Thread does not implement proc.Thread (missing SetDX method)
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/threads.go:131:14: t.SetPC undefined (type *Thread has no field or method SetPC)
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/threads.go:135:42: cannot use t (type *Thread) as type proc.Thread in argument to bp.CheckCondition:
	*Thread does not implement proc.Thread (missing SetDX method)
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/threads.go:137:26: cannot use t (type *Thread) as type proc.Thread in argument to proc.GetG:
	*Thread does not implement proc.Thread (missing SetDX method)
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/threads.go:167:9: undefined: registers
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/threads.go:173:10: t.restoreRegisters undefined (type *Thread has no field or method restoreRegisters, but does have RestoreRegisters)
../../pkg/mod/github.com/go-delve/delve@v1.4.0/pkg/proc/native/threads.go:173:10: too many errors

This is the output of go env

GO111MODULE="on"
GOARCH="arm"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/opt/sources/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/sources/go/v1.13.5"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/sources/go/v1.13.5/pkg/tool/linux_arm"
GCCGO="gccgo"
GOARM="6"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build260717664=/tmp/go-build -gno-record-gcc-switches"

And this is the output of uname -a

Linux smartbit 4.19.62-sunxi #5.92 SMP Wed Jul 31 22:07:23 CEST 2019 armv7l GNU/Linux

[thediveo]

Same problem on Raspbian 10 also; I installed go 1.14 via snap. Trying go get github.com/go-delve/delve/cmd/dlv@master fails with:

../../go/pkg/mod/github.com/go-delve/delve@v1.4.1-0.20200314213456-88a0e1727ac8/service/debugger/debugger.go:22:2: found packages native (proc.go) and your_operating_system_and_architecture_combination_is_not_supported_by_delve (support_sentinel.go) in /home/harald/go/pkg/mod/github.com/go-delve/delve@v1.4.1-0.20200314213456-88a0e1727ac8/pkg/proc/native

[sethwklein]

Seems like we need an ARM32 issue we can redirect these comments to?

[ethanpailes]

I think the FAQ should be updated. I was surprised when I read that arm64 was not supported right after successfully using delve on a linux/arm64 platform (which is awesome!). I don't know if it is fully supported on all OS variants yet, so I didn't want to open a drive by PR.