-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add arm-linux support to delve #2122
Conversation
So great. |
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.
How do we test this?
…p break instruction on arm. 2. Move breakpointInstr calc outside of for loop.
# Conflicts: # go.sum
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.
In a previous comment I was asking "How do we test this?". This is a question we need to find an answer to. We like to have continuous integration for the architectures we support.
nextInstrLen := t.BinInfo().Arch.MaxInstructionLength() | ||
nextInstrBytes := make([]byte, nextInstrLen) | ||
var err error | ||
t.dbp.execPtraceFunc(func() { |
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.
Why not just use t.ReadMemory (here and in the other places in this function where PtracePeekData is called)?
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.
As this is inside low level emulation of ptrace singlestep, I want to make sure it first enter the context of ptrace channel, then do the peek and poke work, so I skip the upper Read/WriteMemory function, and use ptrace function directly.
Yes, currently I do only a little test on raspberry pi4, and I am looking for help to make a more coverage test, do we have any guideline to make such test on different platform? Thanks. |
So far we've gotten along using free services like travis, see |
Regarding testing this, I tried just adding an Additionally the tests hang randomly on my raspberrypi inside |
Got, let me check with my arm device. |
Can confirm d75633f works on my Raspberry Pi 3 with an armhf type processor. |
So no success, to make delve work on a 32bit raspberry Pi OS yet? Just asking, because I just spent more than 2 hours trying to find a 32bit version for raspbian. It should be mentioned in the documentation. |
magic I just tested it and it works! |
spoke too soon, |
I've been holding off on a deeper review of this since we've never been able to answer the question of how do we have CI for this? I agree 32-bit ARM support would be great, but we need CI to verify this (I don't even have a Pi or other 32-bit ARM system to test this on, unfortunately). |
@derekparker we could probably do the same thing we do on 386 and run it inside docker. If the kernel is compiled with compatibility with arm32 binaries the tests can be run directly on arm64. See my comment #2122 (comment). The problem however is that it randomly hangs inside singleStep. |
Ack, alright that makes sense. @puppywang will you be able to investigate this outstanding issue? |
Another option I discovered recently would be to use a GitHub Action and to define a "local runner" ... there a RPi could possibly be setup as local runner. |
And to the cross compiling on a non-arm machine. Was having similar issues with cross compiling some Go application using CGO to 32bit mips and solved that by using a toolchain from the OpenWRT project and setting CC to a gcc version built for building mips. Currently I'm doing the same for an OpenWRT system intended for arm 32bit systems, so this could be used ... however building the OpenWRT toolchain does consume quite a bit of CI-time and might drain the resources an open-source project has available. |
or use the new Balena open fleet :) |
So yesterday I successfully used what we use for building our application for arm32 devices and was able to compile the arm version on my normal ubuntu laptop (So it should be buildable on a normal CI agent or in a Docker container). I was able to run the Delve binary on my edge device, but yes ... I also did encounter these lockups. Is there anything I can help with? |
i am using a patched dlv-binary (the code of the mr) and go 1.17 on linux-arm7 and remote-debugging. work's like charm until now. |
Last time I looked at this it didn't pass most of the tests reliably, so there are no plans at the moment to merge this. If you want to rebase it and fix the problems yourself see: https://github.com/go-delve/delve/blob/master/Documentation/internal/portnotes.md |
Closing stale PR. |
This is the intial support of arm arch for linux os, to address the problem in this issue #20, The arm-linux's ptrace is lacking support of PTRACE_SINGLESTEP, so we need to emulate it by setup breakpoint at any possible next instructions, and then continue execution. I try to fix all the bug that I found, but there may still have plenty of them. Any code review comments is welcome, thanks.