Open longwuyuan opened 5 years ago
I think this is unrelated to Neovim. You get this error just by executing
go get -u github.com/derekparker/delve/cmd/dlv
apologies. i should have mentioned that myself. its true. goal was to use nvim with delve. thanks for comment. do you think there is a solution or is it broken
Probably this is a duplicate/related to #213
Very likely but somebody needs to confirm
yeah, it's quite similar. OpenBSD also supports ptrace, so using the freebsd bits could work.
will try it out sometime next week.
@fbettag, did you get any further with supporting OpenBSD? FreeBSD support has been merged a few weeks ago: https://github.com/go-delve/delve/issues/213.
Haven’t looked at it since, very busy atm :/
any thoughts on this
Just gave it a try to install delve on OpenBSD 6.7 claiming it being FreeBSD. Doesn't seem to work.
$ GOOS=freebsd go get github.com/go-delve/delve/cmd/dlv go: downloading github.com/peterh/liner v0.0.0-20170317030525-88609521dc4b go: downloading github.com/mattn/go-colorable v0.0.0-20170327083344-ded68f7a9561 go: downloading github.com/mattn/go-isatty v0.0.3 go: downloading github.com/sirupsen/logrus v1.6.0 go: downloading github.com/cosiner/argv v0.1.0 go: downloading golang.org/x/sys v0.0.0-20200625212154-ddb9806d33ae go: downloading go.starlark.net v0.0.0-20200821142938-949cc6f4b097 go: downloading github.com/google/go-dap v0.2.0 go: downloading gopkg.in/yaml.v2 v2.2.1 go: extracting gopkg.in/yaml.v2 v2.2.1 go: downloading golang.org/x/arch v0.0.0-20190927153633-4e8777c89be4 go: extracting github.com/google/go-dap v0.2.0 go: extracting github.com/cosiner/argv v0.1.0 go: extracting github.com/mattn/go-isatty v0.0.3 go: downloading github.com/hashicorp/golang-lru v0.5.4 go: extracting github.com/mattn/go-colorable v0.0.0-20170327083344-ded68f7a9561 go: extracting github.com/peterh/liner v0.0.0-20170317030525-88609521dc4b go: downloading github.com/inconshreveable/mousetrap v1.0.0 go: extracting go.starlark.net v0.0.0-20200821142938-949cc6f4b097 go: extracting github.com/sirupsen/logrus v1.6.0 go: downloading github.com/cpuguy83/go-md2man v1.0.10 go: downloading github.com/konsorten/go-windows-terminal-sequences v1.0.3 go: extracting github.com/inconshreveable/mousetrap v1.0.0 go: extracting github.com/konsorten/go-windows-terminal-sequences v1.0.3 go: extracting github.com/cpuguy83/go-md2man v1.0.10 go: extracting github.com/hashicorp/golang-lru v0.5.4 go: downloading github.com/russross/blackfriday v1.5.2 go: extracting github.com/russross/blackfriday v1.5.2 go: extracting golang.org/x/sys v0.0.0-20200625212154-ddb9806d33ae go: extracting golang.org/x/arch v0.0.0-20190927153633-4e8777c89be4 go: finding github.com/sirupsen/logrus v1.6.0 go: finding github.com/cpuguy83/go-md2man v1.0.10 go: finding gopkg.in/yaml.v2 v2.2.1 go: finding github.com/russross/blackfriday v1.5.2 go: finding golang.org/x/sys v0.0.0-20200625212154-ddb9806d33ae go: finding github.com/cosiner/argv v0.1.0 go: finding github.com/peterh/liner v0.0.0-20170317030525-88609521dc4b go: finding github.com/google/go-dap v0.2.0 go: finding github.com/hashicorp/golang-lru v0.5.4 go: finding go.starlark.net v0.0.0-20200821142938-949cc6f4b097 go: finding golang.org/x/arch v0.0.0-20190927153633-4e8777c89be4 go: finding github.com/mattn/go-isatty v0.0.3
pkg/proc/native/threads.go:16:21: undefined: waitStatus pkg/proc/native/threads.go:21:18: undefined: osSpecificDetails
Any progress on this issue?
found packages native (proc.go) and your_operating_system_and_architecture_combination_is_not_supported_by_delve (support_sentinel.go) in /home/munnik/go/src/github.com/go-delve/delve/pkg/proc/native
with forcing the os to FreeBSD:
# github.com/go-delve/delve/pkg/proc/native
go/src/github.com/go-delve/delve/pkg/proc/native/proc.go:28:23: undefined: osProcessDetails
go/src/github.com/go-delve/delve/pkg/proc/native/proc.go:56:23: undefined: osProcessDetails
go/src/github.com/go-delve/delve/pkg/proc/native/proc.go:110:13: dbp.kill undefined (type *nativeProcess has no field or method kill)
go/src/github.com/go-delve/delve/pkg/proc/native/proc.go:118:12: dbp.detach undefined (type *nativeProcess has no field or method detach, but does have Detach)
go/src/github.com/go-delve/delve/pkg/proc/native/proc.go:123:10: undefined: killProcess
go/src/github.com/go-delve/delve/pkg/proc/native/threads.go:16:21: undefined: waitStatus
go/src/github.com/go-delve/delve/pkg/proc/native/threads.go:21:18: undefined: osSpecificDetails
flag
I'm considering taking a look at this and hacking on it this weekend, but I wanted to double check whether anyone other subscribers to this issue had made any progress?
Was any progress made on this issue? Thank you.
I, too, would like to debug go on OpenBSD.
I'm also interested in delve on OpenBSD.
Is there a way to sponsor a fix for this? I'm happy to setup a bountysource to encourage someone to tackle the issue so I can move on with my life. Before I do I'm just wondering if there is a better way now that GitHub has a similar program.
@berkeleynerd you could try contacting go port maintainers at ports at openbsd.org.
See https://openports.se for direct personal contact as well.
I'd be contributing financially to such effort, although care must be taken to choose a platform that does not forfeit the money when deadlines are not hit.
@ezaquarii There's no delve port yet so no one to contact yet insofar as I can tell. I did reach out to the admin to see if this is something that has come up in the past and, if so, if they have any recommendations on how to move forward.
I will also reach out to the Go port maintainers directly as they might have some ideas as well. I tried to log into bounty source via Github SSO but ran into an issue. Not sure if that's sporadic, on my end, or a sign of the end of the road for bounty source more generally.
I'll keep at it until I exhaust all available avenues I'm aware of.
@berkeleynerd admin of openports.se? I'm affraid that it's not related to OpenBSD directly and contacting go
port maintainers would be better option. Even if they don't maintain delve
, they probably have insignt knowledge as porting go
to OpenBSD was not a trivial process.
Joel Sing, the maintainer of several OpenBSD packages, responded to my inquiry with the following. I'm posting it here for posterity and possible future action to move delve on OpenBSD forward.
Hi there!
A few of us tracking the delve port for OpenBSD on Github are interesting in creating a bounty (via bounty source or some other similar service) to encourage the development of a port of delve on OpenBSD. For reference, see Support OpenBSD Issue #1477 go-delve/delve (github.com)
If you have any advice or other feedback on this topic please let us know! I have no idea how much we could raise to this end but these things tend to grow over time as awareness grows.?? Kind Regards, Rebecca
I had a bit of a poke at this and there should not be a lot of work involved - I think I've got most of it working (see below). That said, there will a bit of polish required before it could land. I'm also not sure if there is someone who is interested in taking this and continuing work/maintenance on it moving forward.
As for sponsoring or bounty, I've not had any experience or dealings on that front. That said, I have had a few people provide donations via PayPal in the past. There are also some OpenBSD developers who have set up Patreon accounts, which could be another option.
Hope this helps!
Cheers,
Joel
==
delve$ uname -a
OpenBSD delve 7.0 GENERIC.MP#232 amd64
delve$ sysctl kern.version
kern.version=OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021
deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
delve$ pwd
/home/joel/tmp/hello
delve$ cat main.go
package main
import (
"fmt"
)
func main() {
fmt.Println("Hello world!")
}
delve$ ~/go/bin/dlv debug
Type 'help' for list of commands.
(dlv) break main.main
Breakpoint 1 set at 0x4bd213 for main.main() ./main.go:7
(dlv) continue
> main.main() ./main.go:7 (hits total:1) (PC: 0x4bd213)
2:
3: import (
4: "fmt"
5: )
6:
=> 7: func main() {
8: fmt.Println("Hello world!")
9: }
(dlv) bt
0 0x00000000004bd213 in main.main
at ./main.go:7
1 0x000000000043d3db in runtime.main
at /usr/local/go/src/runtime/proc.go:255
2 0x000000000046d9a1 in runtime.goexit
at /usr/local/go/src/runtime/asm_amd64.s:1581
(dlv) goroutines
Goroutine 1 - User: /usr/local/go/src/runtime/asm_amd64.s:350 runtime.systemstack_switch (0x46b960)
Goroutine 2 - User: /usr/local/go/src/runtime/proc.go:367 runtime.gopark (0x43d87d) [force gc (idle)]
Goroutine 3 - User: /usr/local/go/src/runtime/proc.go:367 runtime.gopark (0x43d87d) [GC sweep wait]
Goroutine 4 - User: /usr/local/go/src/runtime/proc.go:367 runtime.gopark (0x43d87d) [GC scavenge wait]
Goroutine 5 - User: /usr/local/go/src/runtime/mfinal.go:162 runtime.runfinq (0x41ada0)
[5 goroutines]
(dlv) next
> main.main() ./main.go:8 (PC: 0x4bd221)
3: import (
4: "fmt"
5: )
6:
7: func main() {
=> 8: fmt.Println("Hello world!")
9: }
(dlv) continue
Hello world!
Process 20135 has exited with status 0
I'm going to note here that we do have some requirements that new ports must meet now. This is to avoid situations like the freebsd port where it lands half-finished and is promptly abandoned.
I asked Joel Sing to provide his proof of concept code. Let's see if something moves here.
I've pushed a branch (https://github.com/4a6f656c/delve/commits/openbsd) that has support for delve on openbsd/amd64. There are a few things to note:
g
. I'll get a change upstream for this, at which point this functionality can be enabled.the failures seem to be a similar set to what FreeBSD has. Most of these are racey and pass most of the time, but fail intermittently
I'd like to reiterate that I think freebsd's port is bad, because of those failures, and I think merging it that state was a mistake. I would not be inclined to merging another port of the same quality.
@aarzilli what could be the problem with race conditions in the test suite?
@4a6f656c TCB changes that must be implemented are on OpenBSD side, I assume? Is that something that will be available in OpenBSD snapshot at some point?
@ezaquarii the tests that fail are meant to detect that the backend correctly detects breakpoints when two threads hit breakpoints close to each other. The problem is that the freebsd backend does not do that correctly for some reason.
Significant parts of the freebsd port were rewritten, the freebsd backend could not be (potentially) a better starting point for an openbsd port.
This would be an amazing present to receive over the holiday vacation. If there were a GitHub sponsor page or similar for this feature I would donate to it in a heartbeat! I suppose the overlap between OpenBSD hobbyists and Go programmers is small but delve is the tool I really miss when nerding out on OpenBSD.
Any opportunities to help fund this? I'd love to see this port done as well.
Please answer the following before submitting your issue:
Note: Please include any substantial examples (debug session output, stacktraces, etc) as linked gists.
dlv version
)? latestgo version
)? 1.11