ARM support - Githubissues

derekparker commented 9 years ago

Add support for ARM processors.

tylerarnold commented 9 years ago

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

ci-iotsyst commented 8 years ago

If this helps, when compiling, I get:

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

dt-rush commented 6 years ago

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

willwp commented 6 years ago

@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 commented 6 years ago

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

gidoBOSSftw5731 commented 6 years ago

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 commented 6 years ago

@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 commented 5 years ago

:-(


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 commented 5 years ago

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 commented 5 years ago

Do we have progress on this?

beiriannydd commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.

avivdolev commented 5 years ago

Hey We are developing on the NVIDIA Jetson Nano board - also arm64 ... Any progress?

Thanks!

seeforschauer commented 5 years ago

@beiriannydd, @willwp let's create a knowledge base for developing: key objectives, required architecture changes, places to change.

vielmetti commented 5 years ago

Happy to help in any way I can (including recruiting experienced Arm developers to the cause).

aarzilli commented 5 years ago

@vielmetti did you see #1690?

dt-rush commented 5 years ago

@tiohlognm great idea. I commented above I'd take a look at this, then took a job and got quite busy, but that has put me in contact with a lot of go, cross-compiling, working with ARM, etc. so I suspect I may be able to help here. Using #1690 as a template / inspiration we should be able to get other arm archs, specifically armv6/7/8/hf for rpi (various versions) and chromebook.

Gigaclank commented 5 years ago

This would be very usefully currently using armv5

hengwu0 commented 5 years ago

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.

christoofar commented 5 years ago

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 :)

hengwu0 commented 4 years ago

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 commented 4 years ago

@hengwu0 any chance for arm32 support?

hengwu0 commented 4 years ago

@hengwu0 any chance for arm32 support?

Sorry, i have no idea on arm32.

bus710 commented 4 years ago

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 commented 4 years ago

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

bus710 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

MattiaCostamagna commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ethanpailes commented 4 years ago

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.

go-delve / delve

ARM support #118