1
0
mirror of https://github.com/golang/go synced 2024-11-23 16:40:03 -07:00
Commit Graph

20357 Commits

Author SHA1 Message Date
Andrew Gerrand
dc089574c4 doc: amend installation instructions
Fixes #8674.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/139320044
2014-09-09 07:35:44 +10:00
Russ Cox
318294286a runtime: enable StackCopyAlways
Let's see how close we are to this being ready.
Will roll back if it breaks any builds in non-trivial ways.

LGTM=r, khr
R=iant, khr, r
CC=golang-codereviews
https://golang.org/cl/138200043
2014-09-08 17:23:40 -04:00
Russ Cox
9e7c22938c runtime: undo stray edit from CL 140380043
Was having serious editor problems on Windows.

TBR=brainman, iant
CC=golang-codereviews
https://golang.org/cl/137370043
2014-09-08 17:01:40 -04:00
Russ Cox
cf622d758c syscall: keep allocated C string live across call to Syscall
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
2014-09-08 16:59:59 -04:00
Russ Cox
201cfe4afb runtime: run sighandler on g0 stack on windows
The sighander has been run at the bottom of the
currently executing goroutine stack, but it's in C,
and we don't want C on our ordinary goroutine stacks.
Worse, it does a lot of stuff, and it might need more
stack space. There is scary code in traceback_windows.go
that talks about stack splits during sighandler.
Moving sighandler to g0 will eliminate the possibility
of stack splits and such, and then we can delete
traceback_windows.go entirely. Win win.

On the builder, all.bat passes with GOARCH=amd64
and all.bat gets most of the way with GOARCH=386
except for a DLL-loading test that I think is unrelated.

Fixes windows build.

TBR=brainman, iant
CC=golang-codereviews
https://golang.org/cl/140380043
2014-09-08 16:56:46 -04:00
Keith Randall
3a3d47db37 runtime: merge panic1.go back into panic.go
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/139370043
2014-09-08 12:33:08 -07:00
Russ Cox
c81a0ed3c5 liblink, runtime: diagnose and fix C code running on Go stack
This CL contains compiler+runtime changes that detect C code
running on Go (not g0, not gsignal) stacks, and it contains
corrections for what it detected.

The detection works by changing the C prologue to use a different
stack guard word in the G than Go prologue does. On the g0 and
gsignal stacks, that stack guard word is set to the usual
stack guard value. But on ordinary Go stacks, that stack
guard word is set to ^0, which will make any stack split
check fail. The C prologue then calls morestackc instead
of morestack, and morestackc aborts the program with
a message about running C code on a Go stack.

This check catches all C code running on the Go stack
except NOSPLIT code. The NOSPLIT code is allowed,
so the check is complete. Since it is a dynamic check,
the code must execute to be caught. But unlike the static
checks we've been using in cmd/ld, the dynamic check
works with function pointers and other indirect calls.
For example it caught sigpanic being pushed onto Go
stacks in the signal handlers.

Fixes #8667.

LGTM=khr, iant
R=golang-codereviews, khr, iant
CC=golang-codereviews, r
https://golang.org/cl/133700043
2014-09-08 14:05:23 -04:00
Keith Randall
526319830b runtime: a few cleanups.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/134630043
2014-09-08 10:14:41 -07:00
David Crawshaw
4c05d32f79 androidtest.bash: adjustment for move from src/pkg to src
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/142740043
2014-09-08 10:07:26 -04:00
Dave Cheney
4a40fb1979 cmd/cc: fix undefined behaviour warning in bv.c
Fixes warning

# _/home/dfc/go/misc/cgo/test/backdoor
/home/dfc/go/src/cmd/cc/bv.c:43:11: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/136330043
2014-09-08 16:06:41 +10:00
Dave Cheney
6a2e844f51 cmd/gc: fix undefined behaviour warning in subr.c
Fixes warning

/home/dfc/go/src/cmd/gc/subr.c:3469:8: runtime error: negation of -9223372036854775808 cannot be represented in type 'int64' (aka 'long'); cast to an unsigned type to negate this value to itself

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/141220043
2014-09-08 15:36:21 +10:00
Rob Pike
31bd41e04b doc/go1.4.txt: src/pkg directory is gone.
CC=golang-codereviews
https://golang.org/cl/139310043
2014-09-07 21:55:02 -07:00
Russ Cox
de4964a78c build: more adjustments for move from src/pkg to src
These were missed in CL 134570043.

Fixes nacl, solaris builds.

TBR=r
CC=golang-codereviews
https://golang.org/cl/136320043
2014-09-08 00:22:40 -04:00
Russ Cox
c007ce824d build: move package sources from src/pkg to src
Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.
2014-09-08 00:08:51 -04:00
Russ Cox
220a6de47e build: adjustments for move from src/pkg to src
This CL adjusts code referring to src/pkg to refer to src.

Immediately after submitting this CL, I will submit
a change doing 'hg mv src/pkg/* src'.
That change will be too large to review with Rietveld
but will contain only the 'hg mv'.

This CL will break the build.
The followup 'hg mv' will fix it.

For more about the move, see golang.org/s/go14nopkg.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/134570043
2014-09-08 00:06:45 -04:00
Brad Fitzpatrick
36ca636fab doc: add a few http items to go1.4.txt
CC=golang-codereviews
https://golang.org/cl/132670045
2014-09-07 20:52:22 -07:00
Brad Fitzpatrick
ae47e044a8 net/http: add Transport.DialTLS hook
Per discussions out of https://golang.org/cl/128930043/
and golang-nuts threads and with agl.

Fixes #8522

LGTM=agl, adg
R=agl, c, adg
CC=c, golang-codereviews
https://golang.org/cl/137940043
2014-09-07 20:48:40 -07:00
Russ Cox
13d0b82bc8 runtime: implement time.now in assembly on plan9, solaris, windows
These all used a C implementation that contained 64-bit divide by 1000000000.
On 32-bit systems that ends up in the 64-bit C divide support, which makes
other calls and ends up using a fair amount of stack. We could convert them
to Go but then they'd still end up in software 64-bit divide code. That would
be okay, because Go code can split the stack, but it's still unnecessary.

Write time·now in assembly, just like on all the other systems, and use the
actual hardware support for 64/32 -> 64/32 division. This cuts the software
routines out entirely.

The actual code to do the division is copied and pasted from the sys_darwin_*.s files.

LGTM=alex.brainman
R=golang-codereviews, alex.brainman
CC=aram, golang-codereviews, iant, khr, r
https://golang.org/cl/136300043
2014-09-07 23:40:59 -04:00
Russ Cox
50fc0f1af6 net/http/httptest: delete TestIssue7264
Now it's failing on Windows:

panic: httptest: failed to listen on a port: listen tcp 127.0.0.1:0:
listen: An operation on a socket could not be performed because the
system lacked sufficient buffer space or because a queue was full.

Since we can't seem to understand what the test is trying to test,
and because it is causing problems on multiple systems,
delete it.

Fixes #7264.

TBR=bradfitz
CC=brainman, golang-codereviews
https://golang.org/cl/141210043
2014-09-07 23:40:27 -04:00
Russ Cox
71de7e7539 runtime: fix semacquire->acquireSudog->malloc->gogc->semacquire loop
This is what broke the build at
http://build.golang.org/log/d9c6d334be16cbab85e99fddc6b4ba034319bd4e

LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/135580043
2014-09-07 23:16:12 -04:00
Russ Cox
902f8d9ca0 net/http/httptest: fix deadlock in TestIssue7264
I am seeing deadlocks waiting on <-inHandler.
It seems to me that there is no guarantee that the
handler actually runs, if the client does

        write header
        close connection

fast enough. The server might see the EOF on the
connection before it manages to invoke the handler.

This change fixes the deadlock, but it may make
the test not actually test anything. Not sure.

LGTM=bradfitz
R=bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/140970043
2014-09-07 20:13:35 -04:00
Russ Cox
b4bfa6c964 runtime: save g to TLS more aggressively
This is one of those "how did this ever work?" bugs.
The current build failures are happening because
a fault comes up while executing on m->curg on a
system-created thread using an m obtained from needm,
but TLS is set to m->g0, not m->curg. On fault,
sigtramp starts executing, assumes r10 (g) might be
incorrect, reloads it from TLS, and gets m->g0, not
m->curg. Then sighandler dutifully pushes a call to
sigpanic onto the stack and returns to it.
We're now executing on the m->curg stack but with
g=m->g0. Sigpanic does a stack split check, sees that
the SP is not in range (50% chance depending on relative
ordering of m->g0's and m->curg's stacks), and then
calls morestack. Morestack sees that g=m->g0 and
crashes the program.

The fix is to replace every change of g in asm_arm.s
with a call to a function that both updates g and
saves the updated g to TLS.

Why did it start happening? That's unclear.
Unfortunately there were other bugs in the initial
checkin that mask exactly which of a sequence of
CLs started the behavior where sigpanic would end
up tripping the stack split.

Fixes arm build.
Fixes #8675.

LGTM=iant
R=golang-codereviews, iant
CC=dave, golang-codereviews, khr, minux, r
https://golang.org/cl/135570043
2014-09-07 19:47:40 -04:00
Russ Cox
2c14dbe458 crypto/tls: print unexpected error in test
Maybe will help us understand Solaris build failure.

TBR=aram
CC=golang-codereviews
https://golang.org/cl/139290043
2014-09-07 09:07:19 -04:00
Russ Cox
fb818eab7f liblink: fix arm wrapper prologue
Fixes arm build.

TBR=khr
CC=golang-codereviews
https://golang.org/cl/132700043
2014-09-07 08:59:20 -04:00
Russ Cox
2034dae94f build: fix windows make.bat
The Unix make.bash builds cmd/dist from *.c.
make.bat apparently does not.

TBR=r
CC=golang-codereviews
https://golang.org/cl/137280043
2014-09-07 07:31:53 -04:00
Russ Cox
c0951701cf cmd/dist: remove goc2c
After the three pending CLs listed below, there will be no more .goc files.

134580043	runtime: move stubs.goc code into runtime.c
133670043	runtime: fix windows syscalls for copying stacks
141180043	runtime: eliminate Go -> C -> block paths for Solaris

LGTM=bradfitz
R=golang-codereviews, bradfitz, dave
CC=golang-codereviews, iant, r
https://golang.org/cl/132680043
2014-09-07 07:23:49 -04:00
Russ Cox
8a7597fd7a runtime: fix nacl/amd64p32 build
Update #8675
Fixes nacl/amd64p32 build.

TBR=khr
CC=golang-codereviews
https://golang.org/cl/141140045
2014-09-07 07:23:18 -04:00
Russ Cox
59dd20f4d3 runtime: fix windows syscalls for copying stacks
Syscall and everything it calls must be nosplit:
we cannot split a stack once Syscall has been invoked,
because we don't know which of its arguments are
pointers.

LGTM=khr, r, alex.brainman
R=dvyukov, iant, khr, r, bradfitz, alex.brainman
CC=golang-codereviews
https://golang.org/cl/133670043
2014-09-06 21:19:24 -04:00
Russ Cox
c01c2c8895 runtime: eliminate Go -> C -> block paths for Solaris
LGTM=aram, r
R=golang-codereviews, aram, r
CC=golang-codereviews, iant, khr
https://golang.org/cl/141180043
2014-09-06 21:16:35 -04:00
Russ Cox
b6951bcc0b runtime: increase stack split limit again
Increase NOSPLIT reservation from 192 to 384 bytes.
The problem is that the non-Unix systems (Solaris and Windows)
just can't make system calls in a small amount of space,
and then worse they do things that are complex enough
to warrant calling runtime.throw on failure.
We don't have time to rewrite the code to use less stack.

I'm not happy about this, but it's still a small amount.

The good news is that we're doing this to get to only
using copying stacks for stack growth. Once that is true,
we can drop the default stack size from 8k to 4k, which
should more than make up for the bytes we're losing here.

LGTM=r
R=iant, r, bradfitz, aram.h
CC=golang-codereviews
https://golang.org/cl/140350043
2014-09-06 21:16:13 -04:00
Russ Cox
7230db9ef8 misc/makerelease: make goimports-safe
LGTM=bradfitz
R=adg, bradfitz, minux
CC=golang-codereviews
https://golang.org/cl/140310045
2014-09-06 21:10:06 -04:00
Russ Cox
9c721aedd5 cmd/yacc: move cmd/yacc/expr to cmd/yacc/testdata/expr
This will keep the go command from trying to build it
when the cmd/ tree is no longer a special case.

Also update doc.go to refer to the correct location.
(It was incorrect even before this CL.)

LGTM=r
R=iant, r
CC=golang-codereviews
https://golang.org/cl/134560043
2014-09-06 15:27:52 -04:00
Russ Cox
e8fc362049 runtime/cgo: use just #include "textflag.h"
This will withstand the src/pkg/ to src/ move.

LGTM=r
R=iant, r
CC=golang-codereviews
https://golang.org/cl/134530044
2014-09-06 15:27:39 -04:00
Russ Cox
a09e61395e runtime: move stubs.goc code into runtime.c
Now that the calling conventions are the same,
there's no danger to using plain C for these.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/134580043
2014-09-06 15:27:26 -04:00
Russ Cox
e8d65b92d7 liblink: fix arm build errors
This was supposed to be in CL 135490044
but got lost in a transfer from machine to machine.

TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/135560043
2014-09-06 14:53:44 -04:00
Aram Hăvărneanu
b4c28d9180 runtime, syscall: rewrite syscall_solaris.goc in Go
LGTM=dave, rsc
R=khr, dvyukov, dave, gobot, rsc
CC=golang-codereviews, rsc
https://golang.org/cl/133220044
2014-09-06 19:35:46 +02:00
Russ Cox
8473695797 runtime: fix panic/wrapper/recover math
The gp->panicwrap adjustment is just fatally flawed.
Now that there is a Panic.argp field, update that instead.
That can be done on entry only, so that unwinding doesn't
need to worry about undoing anything. The wrappers
emit a few more instructions in the prologue but everything
else in the system gets much simpler.

It also fixes (without trying) a broken test I never checked in.

Fixes #7491.

LGTM=khr
R=khr
CC=dvyukov, golang-codereviews, iant, r
https://golang.org/cl/135490044
2014-09-06 13:19:08 -04:00
Keith Randall
8620e2b04e runtime: badreflectcall runs on the G stack - convert to Go.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/136260043
2014-09-06 10:12:47 -07:00
Keith Randall
dbed4e9b4f runtime: get rid of other Go->C calls in test exports.
testSchedLocal* tests need to malloc now because their
stack frames are too big to fit on the G0 stack.

LGTM=iant
R=golang-codereviews, iant, khr
CC=golang-codereviews
https://golang.org/cl/133660043
2014-09-06 10:07:23 -07:00
Keith Randall
0e19a3d6d0 runtime: move gostringw and gogobytes test stubs to Go.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/141150043
2014-09-05 15:01:09 -07:00
Keith Randall
005806cab1 runtime: run getgcmask on the M stack.
LGTM=rsc
R=rsc, khr
CC=golang-codereviews
https://golang.org/cl/132660043
2014-09-05 14:59:31 -07:00
Russ Cox
277ef8fa07 runtime: disable StackCopyAlways
I forgot to clear this before submitting.

TBR=khr
CC=golang-codereviews
https://golang.org/cl/132640044
2014-09-05 17:00:32 -04:00
Russ Cox
f8f630f5ec runtime: use reflect.call during panic instead of newstackcall
newstackcall creates a new stack segment, and we want to
be able to throw away all that code.

LGTM=khr
R=khr, iant
CC=dvyukov, golang-codereviews, r
https://golang.org/cl/139270043
2014-09-05 16:51:45 -04:00
Russ Cox
fcbe51c9e3 misc/cgo/test: make issue5548 test pickier
If there is doubt about passing arguments correctly
(as there is in this test), there should be doubt about
getting the results back intact too. Using 0 and 1
(especially 0 for success) makes it easy to get a PASS
accidentally when the return value is not actually
being propagated. Use less common values.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/141110043
2014-09-05 14:59:09 -04:00
Russ Cox
4b3906fec3 runtime: handle nil ptr load/store in arm software floating point
We cannot let a real panic start there, because there is C code
on the stack, and worse, there is an assembly frame with a
saved copy of the registers and we have no idea which ones
are pointers.

Instead, detect the nil ptr load/store and return out of the C
and assembly into a stub that will start the call to sigpanic.

Fixes GOARM=5 build.

LGTM=iant
R=golang-codereviews, iant
CC=dave, golang-codereviews, minux, r
https://golang.org/cl/138130043
2014-09-05 14:58:54 -04:00
Russ Cox
f93e21ac24 runtime: clean up sigqueue.go
Minor changes to make logic clearer.
Observed while working on the conversion.

LGTM=iant, dvyukov
R=dvyukov, iant
CC=golang-codereviews
https://golang.org/cl/140250043
2014-09-05 14:38:29 -04:00
Alex Brainman
0f9b6affb7 net: temporarily skip TestAcceptIgnoreSomeErrors
Update #8662

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/138120043
2014-09-05 08:48:21 -07:00
Keith Randall
8217b4a203 runtime: convert panic/recover to Go
created panic1.go just so diffs were available.
After this CL is in, I'd like to move panic.go -> defer.go
and panic1.go -> panic.go.

LGTM=rsc
R=rsc, khr
CC=golang-codereviews
https://golang.org/cl/133530045
2014-09-05 10:04:16 -04:00
Russ Cox
e0f08b938a runtime: use cas loop to coordinate with sigprof
sigprof and setcpuprofilerate coordinate the enabling/disabling
of the handler using a Mutex. This has always been a bit dodgy:
setcpuprofilerate must be careful to turn off signals before acquiring
the lock to avoid a deadlock.

Now the lock implementations use onM, and onM isn't okay on the
signal stack. We know how to make it okay, but it's more work than
is probably worth doing.

Since this is super-dodgy anyway, replace the lock with a simple
cas loop. It is only contended if setcpuprofilerate is being called,
and that doesn't happen frequently enough to care about the
raw speed or about using futexes/semaphores.

TBR to fix freebsd/amd64 and dragonfly/amd64 builds.
Happy to make changes in a follow-up CL.

TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/141080044
2014-09-04 23:14:21 -04:00
Russ Cox
83824639c3 syscall: in linux/arm Syscall, zero R3, R4, R5
The general kernel system call interface
takes 6 arguments: R0, R1, R2, R3, R4, R5.

Syscall is for calls that only need 3.
The amd64 and 386 versions zero the extra arg registers,
but the arm version does not.

func utimensat calls Syscall with 3 arguments.
The kernel expects a 4th argument.
That turns out to be whatever is in R3 at the time of the call.
CL 137160043 changed various pieces of code and apparently
changed the value left in R3 at the time of utimensat's Syscall.
This causes the kernel to return EINVAL.

Change linux/arm Syscall to zero R3, R4, R5, so that calls will
behave deterministically, even if they pass too few arguments.

Arguably, utimensat could be fixed too, but the predictable
zeroing is certainly worth doing, and once done utimensat's
use of Syscall is fine.

Fixes arm build.

TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/141080043
2014-09-04 23:12:10 -04:00