The Linux kernel faccessat system call does not take a flags parameter.
The flag parameter to the C library faccessat function is implemented in C.
The unix.Faccessat function takes a flags parameter. In older releases
we have passed the flags parameter to the kernel, which ignored it.
In CL 119495 we started returning an error if any flags were set.
That seems clearly better than ignoring them, but it turns out that some
code was using the flags. The code was previously subtly broken.
Now it is obviously broken. That is better, but we can do better still:
we can implement the flags as the C library does. That is what this CL does.
Change-Id: I02d4bb981ebd39eb35e47c6e5281f85eaea68016
Reviewed-on: https://go-review.googlesource.com/126516
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For pairs of GOARCH values that can execute each other's binaries on
the same system, such as 386 and amd64, add the definitions and
functions required to fetch and set registers when debugging either
variant.
Fixesgolang/go#9739
Change-Id: I7896ddef7d341ffaee56614ebd080dc38c708ed4
Reviewed-on: https://go-review.googlesource.com/73555
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
The flags parameter was added in https://golang.org/cl/7917. In that CL
the reviewers discussed adding UnlinkAt and changing Unlinkat, and opted
for the latter.
Unfortunately, I then undid that in https://golang.org/cl/10032, which
was a backport of (among others) https://golang.org/cl/5837. I didn't
notice that in the syscall package 5837 removed Unlinkat with two
parameters, but the port to the x/sys/unix package removed Unlinkat with
three parameters. Argh.
This CL effectively restores 7917, by adding the parameter back.
Fixesgolang/go#9923.
Change-Id: I8fe218ac637d0eb0346b63b596666671374bd19f
Reviewed-on: https://go-review.googlesource.com/18981
Reviewed-by: Rob Pike <r@golang.org>
Go1.4 does not recognize arm64 and ppc64le as valid GOARCH values, so
we need explicit build tags.
Change-Id: I1a886c132ae398d9f92b2c2b33d2a4827bbdb9d4
Reviewed-on: https://go-review.googlesource.com/10083
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This copies http://golang.org/cl/8723 from the syscall package.
Quoting the original CL:
This is clumsy, but currently cover tool fails as:
$ go test -run=none -cover syscall
syscall_linux_amd64.go:15: can only use //go:noescape with external func imp
FAIL syscall [build failed]
This happens because cover tool mishandles //go: comments.
r and gri said that fixing cover is infeasible due to go/ast limitations.
So at least fix the offending code so that coverage works.
This come up in context of coverage-guided fuzzing which works best
with program-wide coverage.
Change-Id: Id9e243968a4eb7ae75a585877fdf3192c89e419c
Reviewed-on: https://go-review.googlesource.com/10035
Reviewed-by: Rob Pike <r@golang.org>
This brings over three CLs from the main syscall package:
http://golang.org/cl/5833http://golang.org/cl/5835http://golang.org/cl/5837
Pipe, Pipe2, and Dup2 are moved from syscall_linux.go to the GOARCH
specific variants. On 386 and amd64, Linux kernel version 2.6.23 (the
documented minimum Linux kernel version the Go distribution supports)
does not support the pipe2 system call, so Pipe continues to call
pipe. On ARM, Pipe now calls pipe2.
Several system calls are reimplemented in terms of the *at syscalls,
passing AT_FDCWD to indicate that pathnames are to be interpreted
relative to the current directory. The *at syscalls were added in
Linux kernel version 2.6.16.
This is in preparation for arm64 support, as the arm64 Linux kernel
does not provide the traditional syscall variants.
Change-Id: Id6bc6097dc5f4324cd9e429c5e1f3a411a08ce42
Reviewed-on: https://go-review.googlesource.com/10032
Reviewed-by: Rob Pike <r@golang.org>
With these changes the package builds, and the tests pass, using gccgo
on amd64 GNU/Linux. I have not tested other systems but I don't know
why they wouldn't work.
Change-Id: I727365daef55f158657eb89afbfcdbf3334610d1
Reviewed-on: https://go-review.googlesource.com/9842
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This avoids hanging when a Go program uses a FUSE filesystem and the
dup system call has to close a file descriptor. When dup uses
RawSyscall then the goroutine calling dup will occupy a scheduler slot
(a p structure) during the call, and may block waiting for some other
goroutine to respond to the close call on the FUSE filesystem.
Changing to Syscall avoids the problem. This makes Dup a tiny bit
slower but is quite unlikely to make a difference for any real
programs.
Update golang/go#10202.
Change-Id: I590c5c9a04e0a1281a85dc553c7592fa83949ac7
Reviewed-on: https://go-review.googlesource.com/8056
Reviewed-by: Rob Pike <r@golang.org>
Import syscall so that Kill can refer to syscall.Signal. Drop
termios constants from types_linux.go--all other systems get
them from mkerrors.sh.
Fixesgolang/go#8865.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/152980044
Ian Lance Taylor