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

cmd/link: use libsystem_kernel.dylib or libSystem.dylib for syscalls on macOS #17490

Open
copumpkin opened this Issue Oct 17, 2016 · 24 comments

Comments

Projects
None yet
10 participants
@copumpkin

copumpkin commented Oct 17, 2016

As I understand it, Go currently has its own syscall wrappers for Darwin. This is explicitly against what Apple recommends, precisely because they're not willing to commit to a particular syscall ABI. This leads to issues like #16570, and although we've been lucky in that things have generally been backward-compatible so far, there's no guarantee that it'll continue to happen. It doesn't seem inconceivable to me that we'd at some point end up having to specify "build for macOS 10.13+" vs. "build for 10.12 and below", for example.

Linking against libsystem_kernel.dylib (or the broader libSystem.dylib) would put Go back in line with Apple's recommendations for the platform, and the library is guaranteed to exist on all macOS boxes.

Apologies if this has been suggested before and people have already gone over good reasons not to do it, but I'm currently struggling to figure out what appears to be another Sierra incompatibility related to #16570 above (still haven't figured it out enough to post a reproducible bug) and am wishing we didn't have to deal with these issues.

@ianlancetaylor ianlancetaylor changed the title from Consider linking against libsystem_kernel.dylib or libSystem.dylib on macOS? to cmd/link: link against libsystem_kernel.dylib or libSystem.dylib on macOS Oct 18, 2016

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Oct 18, 2016

I agree that we have to do this. I'm not sure who is actually going to do it, though.

@quentinmit

This comment has been minimized.

Contributor

quentinmit commented Oct 18, 2016

Note that the trouble with #16570 comes from fetching the current time, and that is something that is so performance critical that we might want to continue to use our own implementation even if we use libSystem for other syscall.

@crawshaw

This comment has been minimized.

Contributor

crawshaw commented Oct 18, 2016

We got into a discussion about how to do this over on #17200. I believe this can be done without forcing external linking. But I also don't know who is going to do it, my plate is full for the foreseeable future.

@rsc

This comment has been minimized.

Contributor

rsc commented Jan 4, 2017

Agree we should do this at some point. It's not terribly high priority though.

@rsc rsc added NeedsFix and removed NeedsDecision labels Jan 4, 2017

@rsc rsc changed the title from cmd/link: link against libsystem_kernel.dylib or libSystem.dylib on macOS to cmd/link: use libsystem_kernel.dylib or libSystem.dylib for syscalls on macOS Mar 8, 2017

@rsc

This comment has been minimized.

Contributor

rsc commented Mar 8, 2017

This is about using the system calls. We already link against libSystem.dylib when cgo is in use.

@hirochachacha

This comment has been minimized.

Contributor

hirochachacha commented Jul 20, 2017

Hi, I made a CL for x86. https://go-review.googlesource.com/c/50290/
Could someone review it (after development cycle open) ?
If the overall design is OK, I'd like do something in go 1.10. Thank you.

@gopherbot

This comment has been minimized.

gopherbot commented Jul 20, 2017

CL https://golang.org/cl/50290 mentions this issue.

@bradfitz bradfitz modified the milestones: Go1.10, Go1.9Maybe Jul 20, 2017

@gopherbot

This comment has been minimized.

gopherbot commented Aug 11, 2017

Change https://golang.org/cl/54871 mentions this issue: cmd/internal/obj/x86: don't apply workaround for solaris to darwin

gopherbot pushed a commit that referenced this issue Aug 17, 2017

cmd/internal/obj/x86: don't apply workaround for solaris to darwin
Currently, we have a workaround for solaris that enforce aboslute
addressing for external symbols. However, We don't want to use the
workaround for darwin.
This CL also refactors code a little bit, because the original function
name is not appropriate now.

Updates #17490

Change-Id: Id21f9cdf33dca6a40647226be49010c2c324ee24
Reviewed-on: https://go-review.googlesource.com/54871
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@rsc

This comment has been minimized.

Contributor

rsc commented Nov 22, 2017

Despite the release-blocker label I don't see this happening for Go 1.10. Moving to Go 1.11. If we really want to do this we need to make sure work starts at the beginning of the cycle.

@rsc rsc modified the milestones: Go1.10, Go1.11 Nov 22, 2017

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 22, 2017

Nick Kledzik suggested in e-mail:

There is a middle ground that some JIT creators use, which is to wrap their JITed code in a “boilerplate” mach-o.

For the Go case, since you already generate the wrapper mach-o structure for executables, you expand that a bit, and standard content for linking to libSystem.dylib. This would include the stubs (PLT) section and lazy pointer section (GOT), and the LINKEDIT stuff to bind them for all the POSIX calls Go supports. The Go compiler then calls the stub (PLT) instead of directly inlining the syscall.

The new mach-o content would be the same for all Go executables, so you don’t need a linker. You write a C program that calls all POSIX functions Go supports and compile/link that once, and copy the stubs/lazy pointer sections and LINKEDIT content for use as your boilerplate.

This won’t solve the thread local issue, but will make Go executables true dynamic executables and free Apple to evolve the private libSystem/kernel syscall interface.

gopherbot pushed a commit that referenced this issue Apr 30, 2018

runtime,cmd/ld: on darwin, create theads using libc
Replace thread creation with calls to the pthread
library in libc.

Update #17490

Change-Id: I1e19965c45255deb849b059231252fc6a7861d6c
Reviewed-on: https://go-review.googlesource.com/108679
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot

This comment has been minimized.

gopherbot commented Apr 30, 2018

Change https://golang.org/cl/110475 mentions this issue: runtime: implement darwin raise with pthread_self and pthread_kill

gopherbot pushed a commit that referenced this issue May 1, 2018

runtime: implement darwin raise with pthread_self and pthread_kill
Convert raise from raw syscalls to using the system pthread library.
As a bonus, raise will now target the current thread instead of the
process.

Updates #17490

Change-Id: I2e44f2000bf870e99a5b4dc5ff5e0799fba91bde
Reviewed-on: https://go-review.googlesource.com/110475
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
@gopherbot

This comment has been minimized.

gopherbot commented May 1, 2018

Change https://golang.org/cl/110437 mentions this issue: runtime: move more syscalls to libc on Darwin

@gopherbot

This comment has been minimized.

gopherbot commented May 1, 2018

Change https://golang.org/cl/110438 mentions this issue: runtime: move open/close/read/write from syscall to libc on Darwin

gopherbot pushed a commit that referenced this issue May 1, 2018

runtime: move open/close/read/write from syscall to libc on Darwin
Update #17490

Change-Id: Ia0bb0ba10dc0bbb299290a60b8228275d55125d7
Reviewed-on: https://go-review.googlesource.com/110438
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot

This comment has been minimized.

gopherbot commented May 1, 2018

Change https://golang.org/cl/110655 mentions this issue: runtime: use libc for nanotime on Darwin

@andlabs

This comment has been minimized.

Contributor

andlabs commented May 1, 2018

Probably the wrong place to ask this, but I am curious: what does MOVL $0xf1, 0xf1 do to trigger a crash? Does it just get assembled to a bunch of icebp instructions?

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented May 1, 2018

MOVL $0xf1, 0xf1 assembles into exactly what it looks like: a store of a value to the memory address 0xf1. Since that memory address is not mapped, it causes a bus error, crashing the program. The advantage of using 0xf1 is that the address will be printed in the stack backtrace, giving a clue where the problem happened.

@gopherbot

This comment has been minimized.

gopherbot commented May 2, 2018

Change https://golang.org/cl/111015 mentions this issue: cmd/link,runtime: move syscalls to to libc on iOS

@gopherbot

This comment has been minimized.

gopherbot commented May 3, 2018

Change https://golang.org/cl/111258 mentions this issue: runtime: fix darwin 386/amd64 stack switches

gopherbot pushed a commit that referenced this issue May 19, 2018

runtime: fix darwin 386/amd64 stack switches
A few libc_ calls were missing stack switches.

Unfortunately, adding the stack switches revealed a deeper problem.
systemstack() is fundamentally flawed because when you do

    systemstack(func() { ... })

There's no way to mark the anonymous function as nosplit.  At first I
thought it didn't matter, as that function runs on the g0 stack.  But
nosplit is still required, because some syscalls are done when stack
bounds are not set up correctly (e.g. in a signal handler, which runs
on the g0 stack, but g is still pointing at the g stack).  Instead use
asmcgocall and funcPC, so we can be nosplit all the way down.

Mid-stack inlining now pushes darwin over the nosplit limit also.
Leaving that as a TODO.
Update #23168

This might fix the cause of occasional darwin hangs.
Update #25181

Update #17490

Change-Id: If9c3ef052822c7679f5a1dd192443f714483327e
Reviewed-on: https://go-review.googlesource.com/111258
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

gopherbot pushed a commit that referenced this issue May 20, 2018

runtime: use libc for nanotime on Darwin
Use mach_absolute_time and mach_timebase_info to get nanosecond-level
timing information from libc on Darwin.

The conversion code from Apple's arbitrary time unit to nanoseconds is
really annoying.  It would be nice if we could replace the internal
runtime "time" with arbitrary units and put the conversion to nanoseconds
only in the places that really need it (so it isn't in every nanotime call).

It's especially annoying because numer==denom==1 for all the machines
I tried.  Makes it hard to test the conversion code :(

Update #17490

Change-Id: I6c5d602a802f5c24e35184e33d5e8194aa7afa86
Reviewed-on: https://go-review.googlesource.com/110655
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

gopherbot pushed a commit that referenced this issue May 21, 2018

cmd/link,runtime: move syscalls to libc on iOS
This CL is the darwin/arm and darwin/arm64 equivalent to CL 108679,
110215, 110437, 110438, 111258, 110655.

Updates #17490

Change-Id: Ia95b27b38f9c3535012c566f17a44b4ed26b9db6
Reviewed-on: https://go-review.googlesource.com/111015
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
@gopherbot

This comment has been minimized.

gopherbot commented Jun 7, 2018

Change https://golang.org/cl/116875 mentions this issue: runtime: use libc's signal functions on Darwin

gopherbot pushed a commit that referenced this issue Jun 12, 2018

runtime: use libc's signal functions on Darwin
sigaction, sigprocmask, sigaltstack, and raiseproc.

Fix bug in mstart_stub where we weren't saving callee-saved registers,
so if an m finished the pthread library calling mstart_stub would
sometimes fail.

Update #17490
Update #22805

Change-Id: Ie297ede0997910aa956834e49e85711b90cdfaa7
Reviewed-on: https://go-review.googlesource.com/116875
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot

This comment has been minimized.

gopherbot commented Jun 13, 2018

Change https://golang.org/cl/118736 mentions this issue: runtime: move semaphore ops from system calls to libc calls on Darwin

gopherbot pushed a commit that referenced this issue Jun 16, 2018

runtime: move semaphore ops from system calls to libc calls on Darwin
This CL removes the last of the direct system calls in the runtime package.
This is the last CL for 1.11.

Use libcCall instead of asmcgocall in a few places I accidentally used
the wrong one.

For 1.12, we need to think about whether/how the syscall package
should be moved over to libc.

Update #17490

Change-Id: I4f0bd9cd6023f662f2e29588266fdfae5233898f
Reviewed-on: https://go-review.googlesource.com/118736
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@randall77

This comment has been minimized.

Contributor

randall77 commented Jul 2, 2018

Package runtime now calls out to libSystem for all its syscall needs. That should fix our dependence on the syscall API for most Go binaries.

Direct use of package syscall still does raw syscalls; it does not use libSystem. There are ~100 exported functions to deal with there, so it's a bunch of additional work. I'm going to leave this issue open for that task, but bump to 1.12. In case anyone sees

  1. An easier way to do it
  2. A reason to do it
  3. Someone to do it

we can continue this work.

@gopherbot

This comment has been minimized.

gopherbot commented Oct 11, 2018

Change https://golang.org/cl/141639 mentions this issue: syscall: implement syscalls on Darwin using libSystem

gopherbot pushed a commit that referenced this issue Nov 7, 2018

syscall: implement syscalls on Darwin using libSystem
There are still some references to the bare Syscall functions
in the stdlib. I will root those out in a following CL.
(This CL is big enough as it is.)
Most are in vendor directories:

cmd/vendor/golang.org/x/sys/unix/
vendor/golang_org/x/net/route/syscall.go
syscall/bpf_bsd.go
syscall/exec_unix.go
syscall/flock.go

Update #17490

Change-Id: I69ab707811530c26b652b291cadee92f5bf5c1a4
Reviewed-on: https://go-review.googlesource.com/c/141639
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot

This comment has been minimized.

gopherbot commented Nov 7, 2018

Change https://golang.org/cl/148257 mentions this issue: syscall: move uses of Syscall to libSystem on darwin

gopherbot pushed a commit that referenced this issue Nov 8, 2018

syscall: move uses of Syscall to libSystem on darwin
Miscellaneous additional conversions from raw syscalls
to using their libc equivalent.

Update #17490

Change-Id: If9ab22cc1d676c1f20fb161ebf02b0c28f71585d
Reviewed-on: https://go-review.googlesource.com/c/148257
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment