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
The goal here is to allow assembly functions to appear in the middle
of a Go stack (having called other code) and still record enough information
about their pointers so that stack copying and garbage collection can handle
them precisely. Today, these frames are handled only conservatively.
If you write
func myfunc(x *float64) (y *int)
(with no body, an 'extern' declaration), then the Go compiler now emits
a liveness bitmap for use from the assembly definition of myfunc.
The bitmap symbol is myfunc.args_stackmap and it contains two bitmaps.
The first bitmap, in effect at function entry, marks all inputs as live.
The second bitmap, not in effect at function entry, marks the outputs
live as well.
In funcdata.h, define new assembly macros:
GO_ARGS opts in to using the Go compiler-generated liveness bitmap
for the current function.
GO_RESULTS_INITIALIZED indicates that the results have been initialized
and need to be kept live for the remainder of the function; it causes a
switch to the second generated bitmap for the assembly code that follows.
NO_LOCAL_POINTERS indicates that there are no pointers in the
local variables being stored in the function's stack frame.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/137520043
Tests will come in a separate CL after the funcdata stuff is resolved.
Update #8696
LGTM=iant, rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/138330045
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
Just go ahead and do it, if something is wrong we'll throw.
Also rip out cc-generated arg ptr maps, they are useless now.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/133690045
Replacing gosched with Gosched broke some builds because
some of the call sites are at times when the stack cannot be grown.
TBR=khr
CC=golang-codereviews
https://golang.org/cl/142000043
Details: Until now, when we saw a key:value pair that fit onto
a single line, we assumed that it should be formatted with a
vtab after the ':' for alignment of its value. This leads to
odd behavior if there are more than one such pair on a line.
This CL changes the behavior such that alignment is only used
for the first pair on a line. This preserves existing behavior
(in the std lib we have composite literals where the last line
contains multiple entries and the first entry's value is aligned
with the values on previous lines), and resolves this issue.
No impact on formatting of std lib, go.tools, go.exp, go.net.
Fixes#8685.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/139430043
A write *p = x that needs a write barrier (not all do)
now turns into runtime.writebarrierptr(p, x)
or one of the other variants.
The write barrier implementations are trivial.
The goal here is to emit the calls in the correct places
and to incur the cost of those function calls in the Go 1.4 cycle.
Performance on the Go 1 benchmark suite below.
Remember, the goal is to slow things down (and be correct).
We will look into optimizations in separate CLs, as part of
the process of comparing Go 1.3 against tip in order to make
sure Go 1.4 runs at least as fast as Go 1.3.
benchmark old ns/op new ns/op delta
BenchmarkBinaryTree17 3118336716 3452876110 +10.73%
BenchmarkFannkuch11 3184497677 3211552284 +0.85%
BenchmarkFmtFprintfEmpty 89.9 107 +19.02%
BenchmarkFmtFprintfString 236 287 +21.61%
BenchmarkFmtFprintfInt 246 278 +13.01%
BenchmarkFmtFprintfIntInt 395 458 +15.95%
BenchmarkFmtFprintfPrefixedInt 343 378 +10.20%
BenchmarkFmtFprintfFloat 477 525 +10.06%
BenchmarkFmtManyArgs 1446 1707 +18.05%
BenchmarkGobDecode 14398047 14685958 +2.00%
BenchmarkGobEncode 12557718 12947104 +3.10%
BenchmarkGzip 453462345 472413285 +4.18%
BenchmarkGunzip 114226016 115127398 +0.79%
BenchmarkHTTPClientServer 114689 112122 -2.24%
BenchmarkJSONEncode 24914536 26135942 +4.90%
BenchmarkJSONDecode 86832877 103620289 +19.33%
BenchmarkMandelbrot200 4833452 4898780 +1.35%
BenchmarkGoParse 4317976 4835474 +11.98%
BenchmarkRegexpMatchEasy0_32 150 166 +10.67%
BenchmarkRegexpMatchEasy0_1K 393 402 +2.29%
BenchmarkRegexpMatchEasy1_32 125 142 +13.60%
BenchmarkRegexpMatchEasy1_1K 1010 1236 +22.38%
BenchmarkRegexpMatchMedium_32 232 301 +29.74%
BenchmarkRegexpMatchMedium_1K 76963 102721 +33.47%
BenchmarkRegexpMatchHard_32 3833 5463 +42.53%
BenchmarkRegexpMatchHard_1K 119668 161614 +35.05%
BenchmarkRevcomp 763449047 706768534 -7.42%
BenchmarkTemplate 124954724 134834549 +7.91%
BenchmarkTimeParse 517 511 -1.16%
BenchmarkTimeFormat 501 514 +2.59%
benchmark old MB/s new MB/s speedup
BenchmarkGobDecode 53.31 52.26 0.98x
BenchmarkGobEncode 61.12 59.28 0.97x
BenchmarkGzip 42.79 41.08 0.96x
BenchmarkGunzip 169.88 168.55 0.99x
BenchmarkJSONEncode 77.89 74.25 0.95x
BenchmarkJSONDecode 22.35 18.73 0.84x
BenchmarkGoParse 13.41 11.98 0.89x
BenchmarkRegexpMatchEasy0_32 213.30 191.72 0.90x
BenchmarkRegexpMatchEasy0_1K 2603.92 2542.74 0.98x
BenchmarkRegexpMatchEasy1_32 254.00 224.93 0.89x
BenchmarkRegexpMatchEasy1_1K 1013.53 827.98 0.82x
BenchmarkRegexpMatchMedium_32 4.30 3.31 0.77x
BenchmarkRegexpMatchMedium_1K 13.30 9.97 0.75x
BenchmarkRegexpMatchHard_32 8.35 5.86 0.70x
BenchmarkRegexpMatchHard_1K 8.56 6.34 0.74x
BenchmarkRevcomp 332.92 359.62 1.08x
BenchmarkTemplate 15.53 14.39 0.93x
LGTM=rlh
R=rlh
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/136380043
The uses of onM in dopanic/startpanic are okay even from the signal stack.
Fixes#8666.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/134710043
The previous implementation used per-socket TCP keepalive options
wrong. For example, it used another level socket option to control
TCP and it didn't use TCP_KEEPINTVL option when possible.
Fixes#8683.
Fixes#8701.
Update #8679
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/136480043
They will both need write barriers at some point.
But until then, no reason why we shouldn't share.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/141330043
The previous implementation had several subtle issues. It's not
clear if any of these could actually be causing the flakiness
problems on openbsd/386, but fixing them should only help.
1. thrsleep() is implemented internally as unlock, then test *abort
(if abort != nil), then tsleep(). Under the current code, that makes
it theoretically possible that semasleep()/thrsleep() could release
waitsemalock, then a racing semawakeup() could acquire the lock,
increment waitsemacount, and call thrwakeup()/wakeup() before
thrsleep() reaches tsleep(). (In practice, OpenBSD's big kernel lock
seems unlikely to let this actually happen.)
The proper way to avoid this is to pass &waitsemacount as the abort
pointer to thrsleep so thrsleep knows to re-check it before going to
sleep, and to wakeup if it's non-zero. Then we avoid any races.
(I actually suspect openbsd's sema{sleep,wakeup}() could be further
simplified using cas/xadd instead of locks, but I don't want to be
more intrusive than necessary so late in the 1.4 release cycle.)
2. semasleep() takes a relative sleep duration, but thrsleep() needs
an absolute sleep deadline. Instead of recomputing the deadline each
iteration, compute it once up front and use (*Timespec)(nil) to signify
no deadline. Ensures we retry properly if there's a spurious wakeup.
3. Instead of assuming if thrsleep() woke up and waitsemacount wasn't
available that we must have hit the deadline, check that the system
call returned EWOULDBLOCK.
4. Instead of assuming that 64-bit systems are little-endian, compute
timediv() using a temporary int32 nsec and then assign it to tv_nsec.
LGTM=iant
R=jsing, iant
CC=golang-codereviews
https://golang.org/cl/137960043
A race exists between the parent and child processes after a fork.
The child needs to access the new M pointer passed as an argument
but the parent may have already returned and clobbered it.
Previously, we avoided this by saving the necessary data into
registers before the rfork system call but this isn't guaranteed
to work because Plan 9 makes no promises about the register state
after a system call. Only the 386 kernel seems to save them.
For amd64 and arm, this method won't work.
We eliminate the race by allocating stack space for the scheduler
goroutines (g0) in the per-process copy-on-write stack segment and
by only calling rfork on the scheduler stack.
LGTM=aram, 0intro, rsc
R=aram, 0intro, mischief, rsc
CC=golang-codereviews
https://golang.org/cl/110680044
The only thing I can see that is really Plan 9-specific
is that the stack pointer used for signal handling used
to have more mapped memory above it.
Specifically it used to have at most 88 bytes (StackTop),
so change the allocation of a 40-byte frame to a 128-byte frame.
No idea if this will work, but worth a try.
Note that "fix" here means get it back to timing out
instead of crashing.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/142840043
The difference between the old and the new (from earlier) code
is that we set stackguard = stack.lo + StackGuard, while the old
code set stackguard = stack.lo. That 512 bytes appears to be
the difference between the profileloop function running and not running.
We don't know how big the system stack is, but it is likely MUCH bigger than 4k.
Give Go/C 8k.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/140440044
Start the stack a few words below the actual top, so that
if something tries to read goexit's caller PC from the stack,
it won't fault on a bad memory address.
Today, heapdump does that.
Maybe tomorrow, traceback or something else will do that.
Make it not a bug.
TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/136450043
For -mode=atomic, we need to read the counters
using an atomic load to avoid a race. Not worth worrying
about when -mode=atomic is set during generation
of the profile, so we use atomic loads always.
Fixes#8630.
LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/141800043
With new interface allocation rules, the old counts were wrong and
so was the commentary.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/142760044
Commit to stack copying for stack growth.
We're carrying around a surprising amount of cruft from older schemes.
I am confident that precise stack scans and stack copying are here to stay.
Delete fallback code for when precise stack info is disabled.
Delete fallback code for when copying stacks is disabled.
Delete fallback code for when StackCopyAlways is disabled.
Delete Stktop chain - there is only one stack segment now.
Delete M.moreargp, M.moreargsize, M.moreframesize, M.cret.
Delete G.writenbuf (unrelated, just dead).
Delete runtime.lessstack, runtime.oldstack.
Delete many amd64 morestack variants.
Delete initialization of morestack frame/arg sizes (shortens split prologue!).
Replace G's stackguard/stackbase/stack0/stacksize/
syscallstack/syscallguard/forkstackguard with simple stack
bounds (lo, hi).
Update liblink, runtime/cgo for adjustments to G.
LGTM=khr
R=khr, bradfitz
CC=golang-codereviews, iant, r
https://golang.org/cl/137410043
I have found better approach, then longer wait.
See CL 134360043 for details.
««« original CL description
runtime/pprof: adjust cpuHogger so that tests pass on windows builders
LGTM=rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/140110043
»»»
LGTM=dave
R=golang-codereviews, dave, dvyukov
CC=golang-codereviews
https://golang.org/cl/133500043
I assumed they were the same when I wrote
cgocallback.go earlier today. Merge them
to eliminate confusion.
I can't tell what gomallocgc did before with
a nil type but without FlagNoScan.
I created a call like that in cgocallback.go
this morning, translating from a C file.
It was supposed to do what the C version did,
namely treat the block conservatively.
Now it will.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/141810043
It already is updating parts of them; we're just getting lucky
retraversing them and not finding much to do.
Change argp to a pointer so that it will be updated too.
Existing tests break if you apply the change to adjustpanics
without also updating the type of argp.
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/139380043
It worked at CL 134660043 on the builders,
so I believe it will stick this time.
LGTM=bradfitz
R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/141280043
Inside a control clause (if ... {}), composite
literals starting with a type name must be parenthesized.
A composite literal used in the array length expression
of an array composite literal is already parenthesized.
Not a valid program, but syntactically is should
be accepted.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/142760043
This should make deferreturn nosplit all the way down,
which should fix the current windows/amd64 failure.
If not, I will change StackCopyAlways back to 0.
TBR=khr
CC=golang-codereviews
https://golang.org/cl/135600043
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
I did this just to clean things up, but it will be important
when we drop the pkg directory later.
LGTM=bradfitz
R=r, bradfitz
CC=golang-codereviews
https://golang.org/cl/132600043
Behavior before this CL:
1. If onM is called on a g0 stack, it just calls the given function.
2. If onM is called on a gsignal stack, it calls badonm.
3. If onM is called on a curg stack, it switches to the g0 stack
and then calls the function.
In cases 1 and 2, if the program then crashes (and badonm always does),
we want to see what called onM, but the traceback stops at onM.
In case 3, the traceback must stop at onM, because the g0
stack we are renting really does stop at onM.
The current code stops the traceback at onM to handle 3,
at the cost of making 1 and 2 crash with incomplete traces.
Change traceback to scan past onM but in case 3 make it look
like on the rented g0 stack, onM was called from mstart.
The traceback already knows that mstart is a top-of-stack function.
Alternate fix at CL 132610043 but I think this one is cleaner.
This CL makes 3 the exception, while that CL makes 1 and 2 the exception.
Submitting TBR to try to get better stack traces out of the
freebsd/amd64 builder, but happy to make changes in a
followup CL.
TBR=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/133620043
The old change worked fine in my client, but my client
must not have been in a completely clean state.
TBR=r
CC=golang-codereviews
https://golang.org/cl/138100043
1) cmd/dist was copying textflag.h to the build include directory,
but only after compiling package runtime. So other packages could
use it, just not runtime. Copy earlier, so that runtime can use it too.
2) We decided for android that anything marked linux is also included
in the build. The generated linux-specific files in cmd/dist must therefore
have explicit +build !android tags, or else you can't have simultaneous
linux/arm and android/arm builds in a single client. The tag was already
there for at least one file, but it was missing from many others.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/134500043
sysAlloc is the only mem function called from Go.
LGTM=iant, khr
R=golang-codereviews, khr, 0intro, iant
CC=dvyukov, golang-codereviews, r
https://golang.org/cl/139210043
Mostly NOSPLIT additions.
Had to rewrite atomic_arm.c in Go because it calls lock,
and lock is too complex.
With this CL, I find no Go -> C calls that can split the stack
on any system except Solaris and Windows.
Solaris and Windows need more work and will be done separately.
LGTM=iant, dave
R=golang-codereviews, bradfitz, iant, dave
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/137160043
The -nocgo builder failed because it has cgo disabled
as well as no USER environment variable:
http://build.golang.org/log/2250abb82f5022b72a12997b8ff89fcdeff094c9
# Checking API compatibility.
Error getting current user: user: Current not implemented on linux/amd64
exit status 1
Don't require the environment variable here.
LGTM=minux
R=dave, adg, minux
CC=golang-codereviews
https://golang.org/cl/140290043
Convert no-op race functions.
Everything else is tiny and gets NOSPLITs.
After this, all that is left on darwin is sysAlloc, panic, and gothrow (all pending).
There may be system-specific calls in other builds.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/140240044
When this code was written, there was no way for Go to
reuse the C function and enum values. Now there is.
LGTM=bradfitz
R=rlh, bradfitz
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/139150045
The original conversion in CL 132090043 cut up
the function in an attempt to avoid converting most
of the code to Go. This contorts the control flow.
While debugging the onM signal stack bug,
I reconverted sigqueue.goc in its entirety.
This restores the original control flow, which is
much easier to understand.
The current conversion is correct, it's just complex
and will be hard to maintain. The new one is as
readable as the original code.
I uploaded sigqueue.goc as the initial copy of
sigqueue.go in the CL, so if you view the diffs
of sigqueue.go comparing against patch set 2 [sic]
it will show the actual starting point.
For example:
https://golang.org/cl/136160043/diff2/20001:60001/src/pkg/runtime/sigqueue.go
LGTM=dvyukov, iant
R=golang-codereviews, dvyukov, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/136160043
The common code is converted, epoll and kqueue are converted.
Windows and solaris are still C.
LGTM=rsc
R=golang-codereviews, rsc, dave
CC=golang-codereviews, iant, khr, rsc
https://golang.org/cl/132910043
I had this right in one of my clients, but apparently not the one I submitted from.
Fixes 386 builds.
TBR=dfc
CC=golang-codereviews
https://golang.org/cl/138000045
The arm5 build breakage at CL 139110043 was caused by
calling funcPC on a lessstack defined as a struct{}.
That symbol ended up with a non-4-aligned address,
which caused the memory fault that broke the builders.
The definition of lessstack was fixed in CL 140880043.
Tracking that down suggested that it would be worth
looking for the same bug elsewhere in the directory.
This is the only one I found.
LGTM=bradfitz
R=golang-codereviews, dave, bradfitz
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/134410043
Some things get converted.
Other things (too complex or too many C deps) get onM calls.
Other things (too simple) get #pragma textflag NOSPLIT.
After this CL, the offending function list is basically:
- panic.c
- netpoll.goc
- mem*.c
- race stuff
- readgstatus
- entersyscall/exitsyscall
LGTM=r, iant
R=golang-codereviews, r, iant
CC=dvyukov, golang-codereviews, khr
https://golang.org/cl/140930043
The implementation and use patterns of onM assume
that they run on either the m->curg or m->g0 stack.
Calling onM from m->gsignal has two problems:
(1) When not on g0, onM switches to g0 and then "back" to curg.
If we didn't start at curg, bad things happen.
(2) The use of scalararg/ptrarg to pass C arguments and results
assumes that there is only one onM call at a time.
If a gsignal starts running, it may have interrupted the
setup/teardown of the args for an onM on the curg or g0 stack.
Using scalararg/ptrarg itself would smash those.
We can fix (1) by remembering what g was running before the switch.
We can fix (2) by requiring that uses of onM that might happen
on a signal handling stack must save the old scalararg/ptrarg
and restore them after the call, instead of zeroing them.
The only sane way to do this is to introduce a separate
onM_signalsafe that omits the signal check, and then if you
see a call to onM_signalsafe you know the surrounding code
must preserve the old scalararg/ptrarg values.
(The implementation would be that onM_signalsafe just calls
fn if on the signal stack or else jumps to onM. It's not necessary
to have two whole copies of the function.)
(2) is not a problem if the caller and callee are both Go and
a closure is used instead of the scalararg/ptrarg slots.
For now, I think we can avoid calling onM from code executing
on gsignal stacks, so just reject it.
In the long term, (2) goes away (as do the scalararg/ptrarg slots)
once everything is in Go, and at that point fixing (1) would be
trivial and maybe worth doing just for regularity.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/135400043
Instead of making asmcgocall call asmcgocall_errno,
make both load args into registers and call a shared
assembly function.
On amd64, this costs 1 word in the asmcgocall_errno path
but saves 3 words in the asmcgocall path, and the latter
is what happens on critical nosplit paths on Windows.
On arm, this fixes build failures: asmcgocall was writing
the arguments for asmcgocall_errno into the wrong
place on the stack. Passing them in registers avoids the
decision entirely.
On 386, this isn't really needed, since the nosplit paths
have twice as many words to work with, but do it for consistency.
Update #8635
Fixes arm build (except GOARM=5).
TBR=iant
CC=golang-codereviews
https://golang.org/cl/134390043
I really hoped we could avoid this nonsense, but it appears not.
Should fix windows/amd64 build breakage.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/137120043
This CL fixes a bug introduced by CL 128820043 which is that
builtin dns stub resolver doesn't work well with literal IPv6
address namesever entries in /etc/resolv.conf.
Also simplifies resolv.conf parser and adds more test cases.
LGTM=iant
R=golang-codereviews, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/140040043
The discriminator in the execution engine was stupid.
Add a test to the parse package too. The problem wasn't there
but the particular case ('e' in a hex integer) was not covered.
Fixes#8622.
LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/133530043
It is fundamentally unsafe to grow the stack once someone
has made a call to syscall.Syscall. That function takes 6 uintptr
arguments, but depending on the call some are pointers.
In fact, some might be pointers to stack values, and we don't know which.
That makes it impossible to copy the stack somewhere else.
Since we want to delete all the stack splitting code, relying only
on stack copying, make sure that Syscall never needs to split the stack.
The only thing Syscall does is:
call entersyscall
make the system call
call exitsyscall
As long as we make sure that entersyscall and exitsyscall
can live in the nosplit region, they won't ask for more stack.
Do this by making entersyscall and exitsyscall set up the
stack guard so that any call to a function with a split check
will cause a crash. Then move non-essential slow-path
work onto the m stack using onM and mark the rest of the
work nosplit. The linker will verify that the chain of nosplits
fits in the total nosplit budget.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/140950043
Because symtab.c was partially converted before,
the diffs are not terribly useful.
The earlier conversion was trying to refactor or
clean up the code in addition to doing the translation.
It also made a mistake by redefining Func to be something
users could overwrite.
I undid those changes, making symtab.go a more
literal line-for-line translation of symtab.c instead.
LGTM=josharian
R=golang-codereviews, dave, bradfitz, josharian
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/140880043
We often saw GC pauses of 0 ns, not just on Windows.
Google Compute Engine timer granularity might suck
too.
LGTM=rsc
R=rsc, dvyukov
CC=golang-codereviews
https://golang.org/cl/140910043
The race was in the old C code.
The new Go code does not have the race
and does not need the check.
LGTM=bradfitz, dvyukov
R=golang-codereviews, bradfitz, dvyukov
CC=golang-codereviews, rlh
https://golang.org/cl/140180043
Ignore memory access on g0/gsignal.
See the issue for context and explanation.
Fixes#8627.
LGTM=khr
R=golang-codereviews, mdempsky, khr
CC=golang-codereviews, rsc
https://golang.org/cl/137070043
Code to bring goroutines to a gc safepoint one at a time,
do some work such as scanning, and restart the
goroutine, and then move on to the next goroutine.
Currently this code does not do much useful work
but this infrastructure will be critical to future
concurrent GC work.
Fixed comments reviewers.
LGTM=rsc
R=golang-codereviews, rsc, dvyukov
CC=golang-codereviews
https://golang.org/cl/131580043
This gives them correct types in Go and also makes it
possible to use them to run Go code on an m stack.
LGTM=iant
R=golang-codereviews, dave, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/137970044
They were in proc.c mainly because there was no portable
traceback source file. As part of converting them to Go,
move to traceback.go.
In order to get access to the PC of _rt0_go,
rename to runtime.rt0_go.
LGTM=r
R=golang-codereviews, r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/139110043
If system is busy burning cpu, it takes long time (about 300ms on
windows builders) to adjust prof thread priority. Once adjusted, prof
thread runs ahead of everyone else, but due to initial slowness, it
does not capture prof snapshots until start-up period is completed.
Change prof thread priority sooner, so it can start captures straight
away.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/134360043
While we are here, give the gc helper a real function name
that will appear in stack traces.
LGTM=rlh
R=rlh
CC=dvyukov, golang-codereviews
https://golang.org/cl/133470043
C and Go calling conventions are now compatible, so we
don't need two versions of this function.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/139080043
The two converted files were nearly identical.
Instead of continuing that duplication, I merged them
into a single traceback.go.
Tested on arm, amd64, amd64p32, and 386.
LGTM=r
R=golang-codereviews, remyoudompheng, dave, r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/134200044
The code I wrote originally works for trivial functions
that are inlined at a call site in another package,
because that was how I wrote my local test.
Make hex(x) work for non-inlinable functions too.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/140830043
Previously, if all connections were busy, we would always
re-prepare the statement on the connection we were assigned from
the pool. That meant that if all connections were busy most of the
time, the number of prepared statements for each connection would
keep increasing over time.
Instead, after getting a free connection, check to see if the
statement has already been prepared on it, and reuse the statement
handle if so.
LGTM=bradfitz
R=golang-codereviews, gobot, bradfitz
CC=golang-codereviews
https://golang.org/cl/116930043
It looks like this has just always been broken:
the race detector handles running Go code on g0 of the main thread
and on g0 of any extra threads created by non-Go code, but it does
not handle running Go code on g0 of non-main threads created by Go.
Handle that.
Should fix the race build failures on the dashboard.
We're running into this now because we are running more
and more Go code on g0.
TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/137910043
The file in repo has been updated recently, but all these changes
are gone off the web site now. It seems web site gets updated once
in a while, so we'll update our file occasionally.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/140780043
The exported Go definitions appearing in mprof.go are
copied verbatim from debug.go.
The unexported Go funcs and types are new.
The C Bucket type used a union and was not a line-for-line translation.
LGTM=remyoudompheng
R=golang-codereviews, remyoudompheng
CC=dvyukov, golang-codereviews, iant, khr, r
https://golang.org/cl/137040043
Adding the #include to defs.c makes it get processed
by cmd/dist, which writes out Go equivalent for all the
C data structures defined in defs.c.
This in turn makes it necessary to define the Plink type,
used in os_plan9.h, in os_plan9.go. Rename it to _Plink
to avoid being exported.
LGTM=0intro, iant
R=golang-codereviews, iant, 0intro
CC=golang-codereviews, r
https://golang.org/cl/132490043
uintptr is better when translating to Go,
and in a few places it's better in C too.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant, khr
https://golang.org/cl/138980043
This change fixes the last known false negative of the race detector --
detection of races between mutating atomic operations and non-atomic operations.
Race runtime already has functions for precise modelling of various atomic operations,
so this change just forwards all atomic ops to race runtime
instead of poor man modeling in sync/atomic package.
Performance is also improved -- full sync/atomic tests run in 60s instead of 85s now.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/111310044
This is needed for callers to be able to keep track of the
writing position within a zip file. Otherwise it's not
possible to compute the size of headers, and the TOC isn't
written until the very end.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/134210043
NO CODE CHANGES HERE
The first conversion was not complete.
This CL doesn't make any actual changes,
but it inserts the missing mprof.goc code
as comments so that the next CL will have
useful diffs.
To make the diffs a bit more useful, removed
all semicolons, ->, and runtime· prefixes as well.
Also corrected order of a few functions in mprof.go
to match original order in mprof.goc.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/134200043
Make the definition of the EpollEvent data field consistent
across architectures, adapt the other use of it in
netpoll_epoll for the new definition, and use uint64 rather
than uintptr.
LGTM=dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/137890043
We can't translate misaligned things to Go, so start rejecting them in C.
The only one in any build appears to be EpollEvent on linux/amd64.
Fix that.
LGTM=r
R=golang-codereviews, r, dvyukov
CC=golang-codereviews, iant
https://golang.org/cl/137020043
In an earlier CL I wrote a separate Go-only version, but that broke Plan 9,
because the Go-only version assumed a non-Plan 9 system.
Translate the real ones instead.
LGTM=r
R=golang-codereviews, r
CC=0intro, golang-codereviews, iant, khr
https://golang.org/cl/140050044
Under the race detector most of the samples go into race runtime,
because of that freebsd race builder constantly fails on this test.
LGTM=bradfitz, rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews, minux
https://golang.org/cl/133370043
Fixes script used to sanity-check the heading-detection heuristic of go/doc.
Fixes#8467.
LGTM=gri
R=golang-codereviews, gobot, gri
CC=golang-codereviews
https://golang.org/cl/128720043
Tested on linux/amd64 too this time.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=dave, golang-codereviews, iant, rsc
https://golang.org/cl/140050043
The net/http package supports setting the HTTP Authorization header
using the Basic Authentication Scheme as defined in RFC 2617, but does
not provide support for extracting the username and password from an
authenticated request using the Basic Authentication Scheme.
Add BasicAuth method to *http.Request that returns the username and
password from authenticated requests using the Basic Authentication
Scheme.
Fixes#6779.
LGTM=bradfitz
R=golang-codereviews, josharian, bradfitz, alberto.garcia.hierro, blakesgentry
CC=golang-codereviews
https://golang.org/cl/76540043
In CL 131450043, which raised it to 160,
I'd raise it to 192 if necessary.
Apparently it is necessary on windows/amd64.
One note for those concerned about the growth:
in the old segmented stack world, we wasted this much
space at the bottom of every stack segment.
In the new contiguous stack world, each goroutine has
only one stack segment, so we only waste this much space
once per goroutine. So even raising the limit further might
still be a net savings.
Fixes windows/amd64 build.
TBR=r
CC=golang-codereviews
https://golang.org/cl/132480043
Renaming the C SysAlloc will let Go define a prototype without exporting it.
For use in cpuprof.goc's translation to Go.
LGTM=mdempsky
R=golang-codereviews, mdempsky
CC=golang-codereviews, iant
https://golang.org/cl/140060043
Actually it mostly deletes code -- alg.print and alg.copy go away.
There was only one usage of alg.print for debug purposes.
Alg.copy is used in chan.goc, but Keith replaces them with
memcopy during conversion, so alg.copy is not needed as well.
Converting them would be significant amount of work
for no visible benefit.
LGTM=crawshaw, rsc, khr
R=golang-codereviews, crawshaw, khr
CC=golang-codereviews, rsc
https://golang.org/cl/139930044
preparing for the syscall package freeze.
the change for issue 8218 is only applied to go.sys/unix.
««« original CL description
syscall: implement setresuid(2) and setresgid(2) on OpenBSD/FreeBSD/DragonflyBSD
Fixes#8218.
LGTM=iant
R=golang-codereviews, iant, minux
CC=golang-codereviews
https://golang.org/cl/107150043
»»»
LGTM=r
R=r, iant, golang-codereviews
CC=golang-codereviews
https://golang.org/cl/138840044
Prevents non-rooted queries with > ndots dots from being tried twice on error.
Fixes#8616.
Benchmark results on linux/amd64
benchmark old ns/op new ns/op delta
BenchmarkGoLookupIPNoSuchHost 8212394 4413293 -46.26%
benchmark old allocs new allocs delta
BenchmarkGoLookupIPNoSuchHost 216 108 -50.00%
benchmark old bytes new bytes delta
BenchmarkGoLookupIPNoSuchHost 17460 8726 -50.02%
LGTM=iant, mikioh.mikioh
R=golang-codereviews, iant, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/137870043
It is anyway, just an allocated one.
Giving it a sized type makes Go access nicer.
LGTM=iant
R=dvyukov, iant
CC=golang-codereviews
https://golang.org/cl/139960043
I had to rename Kevent and Sigaction to avoid the functions of the
same (lowercase) name.
LGTM=iant, r
R=golang-codereviews, r, iant, aram.h
CC=dvyukov, golang-codereviews, khr
https://golang.org/cl/140740043
Signer is an interface to support opaque private keys.
These keys typically result from being kept in special hardware
(i.e. a TPM) although sometimes operating systems provide a
similar interface using process isolation for security rather
than hardware boundaries.
This changes provides interfaces for representing them and
alters crypto/tls so that client certificates can use
opaque keys.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews, jdeprez
https://golang.org/cl/114680043
Needless except that the api tool complains. We could fix that issue instead.
TBR=bradfitz
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/133290043
Run it right before main.init.
There is still some runtime initialization that
happens before runtime.init, and some of that
may call into Go code (for example to acquire locks)
so this timing is not perfect, but I believe it is the
best we can do.
This came up because global variables intialized
to func values are done in the generated init code,
not in the linker.
LGTM=dvyukov
R=dvyukov
CC=golang-codereviews, iant, khr, r
https://golang.org/cl/135210043
As part of the translation of the runtime, we need to rewrite
C printf calls to Go print calls. Consider this C printf:
runtime·printf("[signal %x code=%p addr=%p pc=%p]\n",
g->sig, g->sigcode0, g->sigcode1, g->sigpc);
Today the only way to write that in Go is:
print("[signal ")
printhex(uint64(g->sig))
print(" code=")
printhex(uint64(g->sigcode0))
print(" addr=")
printhex(uint64(g->sigcode1))
print(" pc=")
printhex(uint64(g->sigpc))
print("]\n")
(That's nearly exactly what runtime code looked like in C before
I added runtime·printf.)
This CL recognizes the unexported type runtime.hex as an integer
that should be printed in hexadecimal instead of decimal.
It's a little kludgy, but it's restricted to package runtime.
Other packages can define type hex with no effect at all.
Now we can translate that original printf as the more compact:
print("[signal ", hex(g->sig), " code=", hex(g->sigcode0),
" addr=", hex(g->sigcode1), " pc=", hex(g->sigpc), "]\n")
LGTM=r, iant
R=r, iant
CC=golang-codereviews
https://golang.org/cl/133220043
ErrorContext now has all the information it needs from the Node,
rather than depending on the template that contains it. This makes
it easier for html/template to generate correct locations in its
error messages.
Updated html/template to use this ability where it is easy, which is
not everywhere, but more work can probably push it through.
Fixes#8577.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/130620043
Remove C version of GC.
Convert freeOSMemory to Go.
Restore g0 check in GC.
Remove unknownGCPercent check in GC,
it's initialized explicitly now.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews, khr
https://golang.org/cl/139910043
Breaks on Plan 9, apparently.
The other systems must not run sprintf during all.bash.
I'd write a test but it's all going away.
TBR=r
CC=0intro, golang-codereviews
https://golang.org/cl/133260044
I've started with just one function with 8 arguments,
but stdcall is called from nosplit functions
and 8 args overflow nosplit area.
LGTM=aram, alex.brainman
R=golang-codereviews, aram, alex.brainman, dave
CC=golang-codereviews, iant, khr, rsc
https://golang.org/cl/135090043
PNG filters are applied to get better compression ratio.
It does not make sense to apply them if we are not going
to compress.
LGTM=nigeltao
R=nigeltao
CC=golang-codereviews
https://golang.org/cl/137830043
Also fix a bunch of bugs:
1. Accesses to last_gc must be atomic (it's int64).
2. last_gc still can be 0 during first checks in sysmon, check for 0.
3. forcegc.g can be unitialized when sysmon accesses it:
forcegc.g is initialized by main goroutine (forcegc.g = newproc1(...)),
and main goroutine is unsynchronized with both sysmon and forcegc goroutine.
Initialize forcegc.g in the forcegc goroutine itself instead.
LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/136770043
Shrinks the text segment size by about 1.5% for the "go", "gofmt",
and "camlistored" commands on linux/amd64.
Before:
$ size go gofmt camlistored
text data bss dec hex filename
6506842 136996 105784 6749622 66fdb6 go
2376046 85232 90984 2552262 26f1c6 gofmt
17051050 190256 130320 17371626 10911ea camlistored
After:
$ size go gofmt camlistored
text data bss dec hex filename
6403034 136996 105784 6645814 656836 go
2331118 85232 90984 2507334 264246 gofmt
16842586 190256 130320 17163162 105e39a camlistored
Fixes#8604.
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/137790043
This is a reapplication of CL 93520045 (changeset 5012df7fac58)
since that was lost during the move to an internal package.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/134020043
In revision 05c3fee13eb3, openbsd/386's tfork implementation was
accidentally changed in one instruction from using the "params"
parameter to using the "psize" parameter.
While here, OpenBSD's __tfork system call returns a pid_t which is an
int32 on all OpenBSD architectures, so change runtime.tfork's return
type from int64 to int32 and update the assembly implementations
accordingly.
LGTM=iant
R=rsc, iant
CC=golang-codereviews, jsing
https://golang.org/cl/133190043
Package addition.
PositionFor permits access to both, positions
adjusted by //line comments (like the Position
accessors), and unadjusted "raw" positions
unaffected by //line comments.
Raw positions are required for correct formatting
of source code via go/printer which until now had
to manually fix adjusted positions.
Fixes#7702.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/135110044
This is getting a little annoying, but once the runtime structs are
being defined in Go, these will go away. So it's only a temporary cost.
TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/135940043
'range hash' makes a copy of the hash array in the stack, creating
a very large stack frame. It's just the right amount that it
uses most but not all of the total stack size. If you have a lot
of environment variables, like the builders, then this is too
much and the g0 stack runs out of space.
TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/132350043
In order to support different compression levels, make the
encoder type public, and add an Encoder method to it.
Fixes#8499.
LGTM=nigeltao
R=nigeltao, ruiu
CC=golang-codereviews
https://golang.org/cl/129190043
I changed all the NACL_SYSJMP to NACL_SYSCALL in
an earlier CL, but I missed the fact that NACL_SYSCALL
will push another return PC on the stack, so that the
arguments will no longer be in the right place.
Since we have to make our own call, we also have to
copy the arguments. Do that.
Fixes nacl/386 build.
TBR=minux
CC=golang-codereviews
https://golang.org/cl/135050044
This will allow structs containing Efaces in C to be
manipulated as structs containing real interfaces in Go.
The eface struct is still defined for use by Go code.
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, khr, r
https://golang.org/cl/133980044
Mutex is consistent with package sync, and when in the
unexported Go form it avoids having a conflcit between
the type (now mutex) and the function (lock).
LGTM=iant
R=golang-codereviews, iant
CC=dvyukov, golang-codereviews, r
https://golang.org/cl/133140043
This adds the minimal support for AArch64/arm64 relocations
needed to get cgo to work (when an isomorphic patch is applied
to gccgo) and a test.
This change uses the "AAarch64" name for the architecture rather
than the more widely accepted "arm64" because that's the name that
the relevant docs from ARM such as
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
all use.
Fixes#8533.
LGTM=iant
R=golang-codereviews, aram, gobot, iant, minux
CC=golang-codereviews
https://golang.org/cl/132000043
NaCl requires the addition of a 32-byte "halt sled" at the end
of the text segment. This means that segtext.len is actually
32 bytes shorter than reality. The computation of the file offset
of the end of the data segment did not take this 32 bytes into
account, so if len and len+32 rounded up (by 64k) to different
values, the symbol table overwrote the last page of the data
segment.
The last page of the data segment is usually the C .string
symbols, which contain the strings used in error prints
by the runtime. So when this happens, your program
probably crashes, and then when it does, you get binary
garbage instead of all the usual prints.
The chance of hitting this with a randomly sized text segment
is 32 in 65536, or 1 in 2048.
If you add or remove ANY code while trying to debug this
problem, you're overwhelmingly likely to bump the text
segment one way or the other and make the bug disappear.
Correct all the computations to use segdata.fileoff+segdata.filelen
instead of trying to rederive segdata.fileoff.
This fixes the failure during the nacl/amd64p32 build.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/135050043
The NaCl "system calls" were assumed to have a compatible
return convention with the C compiler, and we were using
tail jumps to those functions. Don't do that anymore.
Correct mistake introduced in newstackcall duringconversion
from (SP) to (FP) notation. (Actually this fix, in asm_amd64p32.s,
slipped into the C compiler change, but update the name to
match what go vet wants.)
Correct computation of caller stack pointer in morestack:
on amd64p32, the saved PC is the size of a uintreg, not uintptr.
This may not matter, since it's been like this for a while,
but uintreg is the correct one. (And on non-NaCl they are the same.)
This will allow the NaCl build to get much farther.
It will probably still not work completely.
There's a bug in 6l that needs fixing too.
TBR=minux
CC=golang-codereviews
https://golang.org/cl/134990043
runtime._sfloat2 now returns the lr value on the stack, not R0.
Credit to Russ Cox for the fix.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/133120045
uintptr or uint64 in the runtime C were turning into uint in the Go,
bool was turning into uint8, and so on. Fix that.
Also delete Go wrappers for C functions.
The C functions can be called directly now
(but still eventually need to be converted to Go).
LGTM=bradfitz, minux, iant
R=golang-codereviews, bradfitz, iant, minux
CC=golang-codereviews, khr, r
https://golang.org/cl/138740043
nanotime1 is not a Go function and must not store its result at 0(FP).
That overwrites some data owned by the caller.
TBR=aram
CC=golang-codereviews
https://golang.org/cl/138730043
Windows needs the return result in AX, but runtime.sighandler
no longer stores it in AX. Load it back during the assembly trampoline.
TBR=brainman
CC=golang-codereviews
https://golang.org/cl/133980043
The Go calling convention uses more stack space than C.
On 64-bit systems we've been right up against the limit
(128 bytes, so only 16 words) and doing awful things to
our source code to work around it. Instead of continuing
to do awful things, raise the limit to 160 bytes.
I am prepared to raise the limit to 192 bytes if necessary,
but I think this will be enough.
Should fix current link-time stack overflow errors on
- nacl/arm
- netbsd/amd64
- openbsd/amd64
- solaris/amd64
- windows/amd64
TBR=r
CC=golang-codereviews, iant
https://golang.org/cl/131450043
To date, the C compilers and Go compilers differed only in how
values were returned from functions. This made it difficult to call
Go from C or C from Go if return values were involved. It also made
assembly called from Go and assembly called from C different.
This CL changes the C compiler to use the Go conventions, passing
results on the stack, after the arguments.
[Exception: this does not apply to C ... functions, because you can't
know where on the stack the arguments end.]
By doing this, the CL makes it possible to rewrite C functions into Go
one at a time, without worrying about which languages call that
function or which languages it calls.
This CL also updates all the assembly files in package runtime to use
the new conventions. Argument references of the form 40(SP) have
been rewritten to the form name+10(FP) instead, and there are now
Go func prototypes for every assembly function called from C or Go.
This means that 'go vet runtime' checks effectively every assembly
function, and go vet's output was used to automate the bulk of the
conversion.
Some functions, like seek and nsec on Plan 9, needed to be rewritten.
Many assembly routines called from C were reading arguments
incorrectly, using MOVL instead of MOVQ or vice versa, especially on
the less used systems like openbsd.
These were found by go vet and have been corrected too.
If we're lucky, this may reduce flakiness on those systems.
Tested on:
darwin/386
darwin/amd64
linux/arm
linux/386
linux/amd64
If this breaks another system, the bug is almost certainly in the
sys_$GOOS_$GOARCH.s file, since the rest of the CL is tested
by the combination of the above systems.
LGTM=dvyukov, iant
R=golang-codereviews, 0intro, dave, alex.brainman, dvyukov, iant
CC=golang-codereviews, josharian, r
https://golang.org/cl/135830043
Every change to g->atomicstatus is now done atomically so that we can
ensure that all gs pass through a gc safepoint on demand. This allows
the GC to move from one phase to the next safely. In some phases the
stack will be scanned. This CL only deals with the infrastructure that
allows g->atomicstatus to go from one state to another. Future CLs
will deal with scanning and monitoring what phase the GC is in.
The major change was to moving to using a Gscan bit to indicate that
the status is in a scan state. The only bug fix was in oldstack where
I wasn't moving to a Gcopystack state in order to block scanning until
the new stack was in place. The proc.go file is waiting for an atomic
load instruction.
LGTM=rsc
R=golang-codereviews, dvyukov, josharian, rsc
CC=golang-codereviews, khr
https://golang.org/cl/132960044
Update #8527
Fixes two warnings:
src/cmd/gc/mparith3.c:255:10: runtime error: shift exponent 52 is too large for 32-bit type 'int'
src/cmd/gc/mparith3.c:254:14: runtime error: shift exponent 52 is too large for 32-bit type 'int'
LGTM=rsc
R=r, dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/134940044
Also make genzabbrs.go more self-contained.
Also run it (on Linux; does that matter?) to update the table.
LGTM=rsc
R=rsc, alex.brainman
CC=golang-codereviews
https://golang.org/cl/128350044
I noticed that 5g doesn't flush the float64 result back to the stack, hence the change in the function signature. I'm wondering if I should also change the signature for the other two functions.
LGTM=rsc
R=minux, josharian, rsc
CC=golang-codereviews
https://golang.org/cl/132990044
There are both many callers and many implementations of these
interfaces, so make the contract explicit. Callers generally
assume this, and at least the standard library and other
implementations obey this, but it's never stated explicitly,
making it somewhat risky to assume.
LGTM=gri, rsc
R=golang-codereviews, gri
CC=golang-codereviews, r, rsc
https://golang.org/cl/132150043
Also: use 0x644 file permission if a new file
is created (should not happen anymore, though).
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/126610044
Simplify the invocation (and speed it up substantially) in preparation
for move to go generate.
LGTM=bradfitz, mpvl
R=mpvl, bradfitz, josharian
CC=golang-codereviews
https://golang.org/cl/135790043
