Skip to content
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

syscall: how to deal with ABI changes? (freebsd in this case) #16735

Closed
keltia opened this issue Aug 16, 2016 · 4 comments
Closed

syscall: how to deal with ABI changes? (freebsd in this case) #16735

keltia opened this issue Aug 16, 2016 · 4 comments

Comments

@keltia
Copy link

@keltia keltia commented Aug 16, 2016

Hello,

  1. What version of Go are you using (go version)?
    1.6 & 1.7 & master 1.8
  2. What operating system and processor architecture are you using (go env)?
    FreeBSD 9.x / 10.3 / upcoming 11.0

An interesting problem: between 8.x and 9.x in 3/2014 (see freebsd/freebsd@b38edcd#diff-6769d113f5fa92d186538ae4c8659029) some structures were changed in the kernel ABI (and thus breaking it). Current Go repo has a copy of the 8.0 if.h file translated in go struct. How would you deal with such an ABI change with respect to the go translation?

In the current FreeBSD port system, we have an patch that re-sync with the current ABI (although it is currently incomplete as it does not deal with ztypes_freebsd_arm.go at all but I'll fix that) and I'd like to see that patch (see https://github.com/freebsd/freebsd-ports/blob/master/lang/go/files/struct-if_data-patch) upstreamed if possible.

The problem is that I'm not sure how (and have some difficulty to test right now) a go compiled binary with the modifications would work on a pre-ABI change system (although it is rather old and unsupported right now, I'd hate to break that) and how, in the go side of things, deal with that (versioned *_freebsd_* files? Something else?).

Thanks.

@ianlancetaylor ianlancetaylor changed the title How to deal with ABI changes? (freebsd in this case) syscall: how to deal with ABI changes? (freebsd in this case) Aug 16, 2016
@ianlancetaylor ianlancetaylor added this to the Go1.8 milestone Aug 16, 2016
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 16, 2016

As far as I can tell, FreeBSD changes ABIs more aggressively than most systems. The FreeBSD port maintainers will have to decide how they want to handle this in Go.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Aug 16, 2016

@keltia, the patch you link to is modifying the "syscall" package, which is frozen. We even document that at the top of the page (https://golang.org/pkg/syscall/), telling users to use https://godoc.org/golang.org/x/sys/unix etc instead.

The Go runtime itself doesn't always use the "syscall" package.

For instance, for the interface data, we actually vendor a copy of https://godoc.org/golang.org/x/net/route instead (into the standard library, privately) which has been updated for various FreeBSD versions.

What was the original problem which motivated the syscall patch? It looks like http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2015-August/315441.html but that was fixed in Go 1.7 by the x/net/route vendoring.

/cc @mikioh

@keltia
Copy link
Author

@keltia keltia commented Aug 16, 2016

@bradfitz thanks for the good news and go 1.7. I'll check with the port maintainer and remove the patch.
@ianlancetaylor we are getting better [at not breaking ABI] :)

@keltia
Copy link
Author

@keltia keltia commented Aug 16, 2016

@bradfitz the maintainer has committed the removal of the patch file and the port is now at 1.7, thanks!

@keltia keltia closed this Aug 16, 2016
@mikioh mikioh modified the milestones: Go1.7, Go1.8 Oct 14, 2016
@golang golang locked and limited conversation to collaborators Oct 14, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.