envi needs to be updated during Setenv so the key can be correctly deleted later with Unsetenv.
Update #8849.
LGTM=0intro
R=bradfitz, 0intro
CC=golang-codereviews
https://golang.org/cl/149300046
In linker, refuse to write conservative (array of pointers) as the
garbage collection type for any variable in the data/bss GC program.
In the linker, attach the Go type to an already-read C declaration
during dedup. This gives us Go types for C globals for free as long
as the cmd/dist-generated Go code contains the declaration.
(Most runtime C declarations have a corresponding Go declaration.
Both are bss declarations and so the linker dedups them.)
In cmd/dist, add a few more C files to the auto-Go-declaration list
in order to get Go type information for the C declarations into the linker.
In C compiler, mark all non-pointer-containing global declarations
and all string data as NOPTR. This allows them to exist in C files
without any corresponding Go declaration. Count C function pointers
as "non-pointer-containing", since we have no heap-allocated C functions.
In runtime, add NOPTR to the remaining pointer-containing declarations,
none of which refer to Go heap objects.
In runtime, also move os.Args and syscall.envs data into runtime-owned
variables. Otherwise, in programs that do not import os or syscall, the
runtime variables named os.Args and syscall.envs will be missing type
information.
I believe that this CL eliminates the final source of conservative GC scanning
in non-SWIG Go programs, and therefore...
Fixes#909.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/149770043
If there is a leading ·, assume there is a Go prototype and
attach the Go prototype information to the function.
If the function is not called from Go and does not need a
Go prototype, it can be made file-local instead (using name<>(SB)).
This fixes the current BSD build failures, by giving functions like
sync/atomic.StoreUint32 argument stack map information.
Fixes#8753.
LGTM=khr, iant
R=golang-codereviews, iant, khr, bradfitz
CC=golang-codereviews, r, rlh
https://golang.org/cl/142150043
This is necessary because syscall.Syscall blocks, and the
garbage collector needs to be able to scan that frame while
it is blocked, and C frames have no garbage collection
information.
Windows builders are broken now due to this problem:
http://build.golang.org/log/152ca9a4be6783d3a8bf6e2f5b9fc265089728b6
LGTM=alex.brainman
R=alex.brainman
CC=golang-codereviews
https://golang.org/cl/144830043
Before, Syscall and friends were having their arguments
treated conservatively. Now they will use the Go prototype,
which will mean the arguments are not considered pointers
at all.
This is safe because of CL 139360044.
The fact that all these non-Solaris systems were using
conservative scanning of the Syscall arguments is why
the failure that prompted CL 139360044 was only
observed on Solaris, which does something completely different.
If we'd done this earlier, we'd have seen the Solaris
failure in more places.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/144730043
Making the child's process group the foreground process group and
placing the child in a specific process group involves co-ordination
between the parent and child that must be done post-fork but pre-exec.
LGTM=iant
R=golang-codereviews, gobot, iant, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/131750044
Given:
p := alloc()
fn_taking_ptr(p)
p is NOT recorded as live at the call to fn_taking_ptr:
it's not needed by the code following the call.
p was passed to fn_taking_ptr, and fn_taking_ptr must keep
it alive as long as it needs it.
In practice, fn_taking_ptr will keep its own arguments live
for as long as the function is executing.
But if instead you have:
p := alloc()
i := uintptr(unsafe.Pointer(p))
fn_taking_int(i)
p is STILL NOT recorded as live at the call to fn_taking_int:
it's not needed by the code following the call.
fn_taking_int is responsible for keeping its own arguments
live, but fn_taking_int is written to take an integer, so even
though fn_taking_int does keep its argument live, that argument
does not keep the allocated memory live, because the garbage
collector does not dereference integers.
The shorter form:
p := alloc()
fn_taking_int(uintptr(unsafe.Pointer(p)))
and the even shorter form:
fn_taking_int(uintptr(unsafe.Pointer(alloc())))
are both the same as the 3-line form above.
syscall.Syscall is like fn_taking_int: it is written to take a list
of integers, and yet those integers are sometimes pointers.
If there is no other copy of those pointers being kept live,
the memory they point at may be garbage collected during
the call to syscall.Syscall.
This is happening on Solaris: for whatever reason, the timing
is such that the garbage collector manages to free the string
argument to the open(2) system call before the system call
has been invoked.
Change the system call wrappers to insert explicit references
that will keep the allocations alive in the original frame
(and therefore preserve the memory) until after syscall.Syscall
has returned.
Should fix Solaris flakiness.
This is not a problem for cgo, because cgo wrappers have
correctly typed arguments.
LGTM=iant, khr, aram, rlh
R=iant, khr, bradfitz, aram, rlh
CC=dvyukov, golang-codereviews, r
https://golang.org/cl/139360044
enforce rule: all kernel data structures and constants
go in syscall module.
move things that should be in syscall out of net.
make net a single package.
R=r
OCL=15985
CL=15994
use -j4 (4-way parallel) in make.bash.
halves time for make.bash on r45
also add libregexp, acid to default build
R=r
DELTA=90 (39 added, 37 deleted, 14 changed)
OCL=15485
CL=15487
tweak os to adjust
move StringToBytes into syscall, at least for now
this program still works:
package main
import os "os"
func main() {
os.Stdout.WriteString("hello, world\n");
a, b := os.NewFD(77).WriteString("no way");
os.Stdout.WriteString(b.String() + "\n");
}
R=rsc
DELTA=263 (59 added, 176 deleted, 28 changed)
OCL=15153
CL=15153
* kick off new os procs (machs) as needed
* add sys·sleep for testing
* add Lock, Rendez
* properly lock mal, sys·newproc, scheduler
* linux syscall arg #4 is in R10, not CX
* chans are not multithread-safe yet
* multithreading disabled by default;
set $gomaxprocs=2 (or 1000) to turn it on
This should build on OS X but may not.
Rob and I will fix soon after submitting.
TBR=r
OCL=13784
CL=13842
