Make the stack traces more readable for new
Go programmers while preserving their utility for old hands.
- Change status number [4] to string.
- Elide frames in runtime package (internal details).
- Swap file:line and arguments.
- Drop 'created by' for main goroutine.
- Show goroutines in order of allocation:
implies main goroutine first if nothing else.
There is no option to get the extra frames back.
Uncomment 'return 1' at the bottom of symtab.c.
$ 6.out
throw: all goroutines are asleep - deadlock!
goroutine 1 [chan send]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:22 +0x8a
goroutine 2 [select (no cases)]:
main.sel()
/Users/rsc/g/go/src/pkg/runtime/x.go:11 +0x18
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:19 +0x23
goroutine 3 [chan receive]:
main.recv(0xf8400010a0, 0x0)
/Users/rsc/g/go/src/pkg/runtime/x.go:15 +0x2e
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:20 +0x50
goroutine 4 [chan receive (nil chan)]:
main.recv(0x0, 0x0)
/Users/rsc/g/go/src/pkg/runtime/x.go:15 +0x2e
created by main.main
/Users/rsc/g/go/src/pkg/runtime/x.go:21 +0x66
$
$ 6.out index
panic: runtime error: index out of range
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:25 +0xb9
$
$ 6.out nil
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x22ca]
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:28 +0x211
$
$ 6.out panic
panic: panic
goroutine 1 [running]:
main.main()
/Users/rsc/g/go/src/pkg/runtime/x.go:30 +0x101
$
R=golang-dev, qyzhai, n13m3y3r, r
CC=golang-dev
https://golang.org/cl/4907048
Allocate Defer on stack during cgo calls, as suggested
by dvyukov. Also includes some comment corrections.
benchmark old,ns/op new,ns/op
BenchmarkCgoCall 669 330
(Intel Xeon CPU 1.80GHz * 4, Linux 386)
R=dvyukov, rsc
CC=golang-dev
https://golang.org/cl/4910041
The corruption can occur when GOMAXPROCS
is changed from >1 to 1, since GOMAXPROCS=1
does not imply there is only 1 goroutine running,
other goroutines can still be not parked after
the change.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4873050
Every time we enter callback from Windows, it is
possible that go exception handler is not at the top
of per-thread exception handlers chain. So it needs
to be installed again. At this moment this is done
by replacing top SEH frame with SEH frame as at time
of syscall for the time of callback. This is incorrect,
because, if exception strike, we won't be able to call
any exception handlers installed inside syscall,
because they are not in the chain. This changes
procedure to add new SEH frame on top of existing
chain instead.
I also removed m sehframe field, because I don't
think it is needed. We use single global exception
handler everywhere.
R=golang-dev, r
CC=golang-dev, hectorchu
https://golang.org/cl/4832060
The change adds specialized type algorithms
for slices and types of size 8/16/32/64/128.
It significantly accelerates chan and map operations
for most builtin types as well as user structs.
benchmark old,ns/op new,ns/op
BenchmarkChanUncontended 226 94
(on Intel Xeon E5620, 2.4GHz, Linux 64 bit)
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4815087
The data race can lead to reads of partially
initialized concurrently mutated symbol data.
The change also adds a simple sanity test
for Caller() and FuncForPC().
R=rsc
CC=golang-dev
https://golang.org/cl/4817058
The data race is on newly published Itab nodes, which are
both unsafely published and unsafely acquired. It can
break on IA-32/Intel64 due to compiler optimizations
(most likely not an issue as of now) and on ARM due to
hardware memory access reorderings.
R=rsc
CC=golang-dev
https://golang.org/cl/4673055
runtime.goidgen can be quite frequently modified and
shares cache line with the following variables,
it leads to false sharing.
50c6b0 b nfname
50c6b4 b nfunc
50c6b8 b nfunc$17
50c6bc b nhist$17
50c6c0 B runtime.checking
50c6c4 B runtime.gcwaiting
50c6c8 B runtime.goidgen
50c6cc B runtime.gomaxprocs
50c6d0 B runtime.panicking
50c6d4 B strconv.IntSize
50c6d8 B src/pkg/runtime/_xtest_.ss
50c6e0 B src/pkg/runtime/_xtest_.stop
50c6e8 b addrfree
50c6f0 b addrmem
50c6f8 b argv
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4673054
This change was adapted from gccgo's libgo/runtime/mem.c at
Ian Taylor's suggestion. It fixes all.bash failing with
"address space conflict: map() =" on amd64 Linux with kernel
version 2.6.32.8-grsec-2.1.14-modsign-xeon-64.
With this change, SysMap will use MAP_FIXED to allocate its desired
address space, after first calling mincore to check that there is
nothing else mapped there.
R=iant, dave, n13m3y3r, rsc
CC=golang-dev
https://golang.org/cl/4438091
The g->sched.sp saved stack pointer and the
g->stackbase and g->stackguard stack bounds
can change even while "the world is stopped",
because a goroutine has to call functions (and
therefore might split its stack) when exiting a
system call to check whether the world is stopped
(and if so, wait until the world continues).
That means the garbage collector cannot access
those values safely (without a race) for goroutines
executing system calls. Instead, save a consistent
triple in g->gcsp, g->gcstack, g->gcguard during
entersyscall and have the garbage collector refer
to those.
The old code was occasionally seeing (because of
the race) an sp and stk that did not correspond to
each other, so that stk - sp was not the number of
stack bytes following sp. In that case, if sp < stk
then the call scanblock(sp, stk - sp) scanned too
many bytes (anything between the two pointers,
which pointed into different allocation blocks).
If sp > stk then stk - sp wrapped around.
On 32-bit, stk - sp is a uintptr (uint32) converted
to int64 in the call to scanblock, so a large (~4G)
but positive number. Scanblock would try to scan
that many bytes and eventually fault accessing
unmapped memory. On 64-bit, stk - sp is a uintptr (uint64)
promoted to int64 in the call to scanblock, so a negative
number. Scanblock would not scan anything, possibly
causing in-use blocks to be freed.
In short, 32-bit platforms would have seen either
ineffective garbage collection or crashes during garbage
collection, while 64-bit platforms would have seen
either ineffective or incorrect garbage collection.
You can see the invalid arguments to scanblock in the
stack traces in issue 1620.
Fixes#1620.
Fixes#1746.
R=iant, r
CC=golang-dev
https://golang.org/cl/4437075
* Reduces malloc counts during gob encoder/decoder test from 6/6 to 3/5.
The current reflect uses Set to mean two subtly different things.
(1) If you have a reflect.Value v, it might just represent
itself (as in v = reflect.NewValue(42)), in which case calling
v.Set only changed v, not any other data in the program.
(2) If you have a reflect Value v derived from a pointer
or a slice (as in x := []int{42}; v = reflect.NewValue(x).Index(0)),
v represents the value held there. Changing x[0] affects the
value returned by v.Int(), and calling v.Set affects x[0].
This was not really by design; it just happened that way.
The motivation for the new reflect implementation was
to remove mallocs. The use case (1) has an implicit malloc
inside it. If you can do:
v := reflect.NewValue(0)
v.Set(42)
i := v.Int() // i = 42
then that implies that v is referring to some underlying
chunk of memory in order to remember the 42; that is,
NewValue must have allocated some memory.
Almost all the time you are using reflect the goal is to
inspect or to change other data, not to manipulate data
stored solely inside a reflect.Value.
This CL removes use case (1), so that an assignable
reflect.Value must always refer to some other piece of data
in the program. Put another way, removing this case would
make
v := reflect.NewValue(0)
v.Set(42)
as illegal as
0 = 42.
It would also make this illegal:
x := 0
v := reflect.NewValue(x)
v.Set(42)
for the same reason. (Note that right now, v.Set(42) "succeeds"
but does not change the value of x.)
If you really wanted to make v refer to x, you'd start with &x
and dereference it:
x := 0
v := reflect.NewValue(&x).Elem() // v = *&x
v.Set(42)
It's pretty rare, except in tests, to want to use NewValue and then
call Set to change the Value itself instead of some other piece of
data in the program. I haven't seen it happen once yet while
making the tree build with this change.
For the same reasons, reflect.Zero (formerly reflect.MakeZero)
would also return an unassignable, unaddressable value.
This invalidates the (awkward) idiom:
pv := ... some Ptr Value we have ...
v := reflect.Zero(pv.Type().Elem())
pv.PointTo(v)
which, when the API changed, turned into:
pv := ... some Ptr Value we have ...
v := reflect.Zero(pv.Type().Elem())
pv.Set(v.Addr())
In both, it is far from clear what the code is trying to do. Now that
it is possible, this CL adds reflect.New(Type) Value that does the
obvious thing (same as Go's new), so this code would be replaced by:
pv := ... some Ptr Value we have ...
pv.Set(reflect.New(pv.Type().Elem()))
The changes just described can be confusing to think about,
but I believe it is because the old API was confusing - it was
conflating two different kinds of Values - and that the new API
by itself is pretty simple: you can only Set (or call Addr on)
a Value if it actually addresses some real piece of data; that is,
only if it is the result of dereferencing a Ptr or indexing a Slice.
If you really want the old behavior, you'd get it by translating:
v := reflect.NewValue(x)
into
v := reflect.New(reflect.Typeof(x)).Elem()
v.Set(reflect.NewValue(x))
Gofix will not be able to help with this, because whether
and how to change the code depends on whether the original
code meant use (1) or use (2), so the developer has to read
and think about the code.
You can see the effect on packages in the tree in
https://golang.org/cl/4423043/.
R=r
CC=golang-dev
https://golang.org/cl/4435042
* Change use of m->g0 stack (aka scheduler stack).
* Provide runtime.mcall(f) to invoke f() on m->g0 stack.
* Replace scheduler loop entry with runtime.mcall(schedule).
Runtime.mcall eliminates the need for fake scheduler states that
exist just to run a bit of code on the m->g0 stack
(Grecovery, Gstackalloc).
The elimination of the scheduler as a loop that stops and
starts using gosave and gogo fixes a bad interaction with the
way cgo uses the m->g0 stack. Cgo runs external (gcc-compiled)
C functions on that stack, and then when calling back into Go,
it sets m->g0->sched.sp below the added call frames, so that
other uses of m->g0's stack will not interfere with those frames.
Unfortunately, gogo (longjmp) back to the scheduler loop at
this point would end up running scheduler with the lower
sp, which no longer points at a valid stack frame for
a call to scheduler. If scheduler then wrote any function call
arguments or local variables to where it expected the stack
frame to be, it would overwrite other data on the stack.
I realized this possibility while debugging a problem with
calling complex Go code in a Go -> C -> Go cgo callback.
This wasn't the bug I was looking for, it turns out, but I believe
it is a real bug nonetheless. Switching to runtime.mcall, which
only adds new frames to the stack and never jumps into
functions running in existing ones, fixes this bug.
* Move cgo-related code out of proc.c into cgocall.c.
* Add very large comment describing cgo call sequences.
* Simpilify, regularize cgo function implementations and names.
* Add test suite as misc/cgo/test.
Now the Go -> C path calls cgocall, which calls asmcgocall,
and the C -> Go path calls cgocallback, which calls cgocallbackg.
The shuffling, which affects mainly the callback case, moves
most of the callback implementation to cgocallback running
on the m->curg stack (not the m->g0 scheduler stack) and
only while accounted for with $GOMAXPROCS (between calls
to exitsyscall and entersyscall).
The previous callback code did not block in startcgocallback's
approximation to exitsyscall, so if, say, the garbage collector
were running, it would still barge in and start doing things
like call malloc. Similarly endcgocallback's approximation of
entersyscall did not call matchmg to kick off new OS threads
when necessary, which caused the bug in issue 1560.
Fixes#1560.
R=iant
CC=golang-dev
https://golang.org/cl/4253054
This functionality might be used in environments
where programs are limited to a single thread,
to simulate a select-driven network server. It is
not exposed via the standard runtime API.
R=r, r2
CC=golang-dev
https://golang.org/cl/4254041
Avoids deadlocks like the one below, in which a stack split happened
in order to call lock(&stacks), but then the stack unsplit cannot run
because stacks is now locked.
The only code calling stackalloc that wasn't on a scheduler
stack already was malg, which creates a new goroutine.
runtime.futex+0x23 /home/rsc/g/go/src/pkg/runtime/linux/amd64/sys.s:139
runtime.futex()
futexsleep+0x50 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:51
futexsleep(0x5b0188, 0x300000003, 0x100020000, 0x4159e2)
futexlock+0x85 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:119
futexlock(0x5b0188, 0x5b0188)
runtime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158
runtime.lock(0x5b0188, 0x7f0d27b4a000)
runtime.stackfree+0x4d /home/rsc/g/go/src/pkg/runtime/malloc.goc:336
runtime.stackfree(0x7f0d27b4a000, 0x1000, 0x8, 0x7fff37e1e218)
runtime.oldstack+0xa6 /home/rsc/g/go/src/pkg/runtime/proc.c:705
runtime.oldstack()
runtime.lessstack+0x22 /home/rsc/g/go/src/pkg/runtime/amd64/asm.s:224
runtime.lessstack()
----- lessstack called from goroutine 2 -----
runtime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158
runtime.lock(0x5b0188, 0x40a5e2)
runtime.stackalloc+0x55 /home/rsc/g/go/src/pkg/runtime/malloc.c:316
runtime.stackalloc(0x1000, 0x4055b0)
runtime.malg+0x3d /home/rsc/g/go/src/pkg/runtime/proc.c:803
runtime.malg(0x1000, 0x40add9)
runtime.newproc1+0x12b /home/rsc/g/go/src/pkg/runtime/proc.c:854
runtime.newproc1(0xf840027440, 0x7f0d27b49230, 0x0, 0x49f238, 0x40, ...)
runtime.newproc+0x2f /home/rsc/g/go/src/pkg/runtime/proc.c:831
runtime.newproc(0x0, 0xf840027440, 0xf800000010, 0x44b059)
...
R=r, r2
CC=golang-dev
https://golang.org/cl/4216045
Fix problems found.
On amd64, various library routines had bigger
stack frames than expected, because large function
calls had been added.
runtime.assertI2T: nosplit stack overflow
120 assumed on entry to runtime.assertI2T
8 after runtime.assertI2T uses 112
0 on entry to runtime.newTypeAssertionError
-8 on entry to runtime.morestack01
runtime.assertE2E: nosplit stack overflow
120 assumed on entry to runtime.assertE2E
16 after runtime.assertE2E uses 104
8 on entry to runtime.panic
0 on entry to runtime.morestack16
-8 after runtime.morestack16 uses 8
runtime.assertE2T: nosplit stack overflow
120 assumed on entry to runtime.assertE2T
16 after runtime.assertE2T uses 104
8 on entry to runtime.panic
0 on entry to runtime.morestack16
-8 after runtime.morestack16 uses 8
runtime.newselect: nosplit stack overflow
120 assumed on entry to runtime.newselect
56 after runtime.newselect uses 64
48 on entry to runtime.printf
8 after runtime.printf uses 40
0 on entry to vprintf
-8 on entry to runtime.morestack16
runtime.selectdefault: nosplit stack overflow
120 assumed on entry to runtime.selectdefault
56 after runtime.selectdefault uses 64
48 on entry to runtime.printf
8 after runtime.printf uses 40
0 on entry to vprintf
-8 on entry to runtime.morestack16
runtime.selectgo: nosplit stack overflow
120 assumed on entry to runtime.selectgo
0 after runtime.selectgo uses 120
-8 on entry to runtime.gosched
On arm, 5c was tagging functions NOSPLIT that should
not have been, like the recursive function printpanics:
printpanics: nosplit stack overflow
124 assumed on entry to printpanics
112 after printpanics uses 12
108 on entry to printpanics
96 after printpanics uses 12
92 on entry to printpanics
80 after printpanics uses 12
76 on entry to printpanics
64 after printpanics uses 12
60 on entry to printpanics
48 after printpanics uses 12
44 on entry to printpanics
32 after printpanics uses 12
28 on entry to printpanics
16 after printpanics uses 12
12 on entry to printpanics
0 after printpanics uses 12
-4 on entry to printpanics
R=r, r2
CC=golang-dev
https://golang.org/cl/4188061
Follow morestack, so that crashes during a stack split
give complete traces. Also mark stack segment boundaries
as an aid to debugging.
Correct various line number bugs with yet another attempt
at interpreting the pc/ln table. This one has a chance at
being correct, because I based it on reading src/cmd/ld/lib.c
instead of on reading the documentation.
Fixes#1138.
Fixes#1430.
Fixes#1461.
throw: runtime: split stack overflow
runtime.throw+0x3e /home/rsc/g/go2/src/pkg/runtime/runtime.c:78
runtime.throw(0x81880af, 0xf75c8b18)
runtime.newstack+0xad /home/rsc/g/go2/src/pkg/runtime/proc.c:728
runtime.newstack()
runtime.morestack+0x4f /home/rsc/g/go2/src/pkg/runtime/386/asm.s:184
runtime.morestack()
----- morestack called from stack: -----
runtime.new+0x1a /home/rsc/g/go2/src/pkg/runtime/malloc.c:288
runtime.new(0x1, 0x0, 0x0)
gongo.makeBoard+0x33 /tmp/Gongo/gongo_robot_test.go:344
gongo.makeBoard(0x809d238, 0x1, 0xf76092c8, 0x1)
----- stack segment boundary -----
gongo.checkEasyScore+0xcc /tmp/Gongo/gongo_robot_test.go:287
gongo.checkEasyScore(0xf764b710, 0x0, 0x809d238, 0x1)
gongo.TestEasyScore+0x8c /tmp/Gongo/gongo_robot_test.go:255
gongo.TestEasyScore(0xf764b710, 0x818a990)
testing.tRunner+0x2f /home/rsc/g/go2/src/pkg/testing/testing.go:132
testing.tRunner(0xf764b710, 0xf763b5dc, 0x0)
runtime.goexit /home/rsc/g/go2/src/pkg/runtime/proc.c:149
runtime.goexit()
R=ken2, r
CC=golang-dev
https://golang.org/cl/4000053
The callback mechanism has been made more flexible.
Eliminated one round of argument copying in Syscall.
Faster Get/SetLastError implemented.
Added gettime for gc perf profiling.
R=rsc, brainman, mattn, rog
CC=golang-dev
https://golang.org/cl/4058046
The old heap maps used a multilevel table, but that
was overkill: there are only 1M entries on a 32-bit
machine and we can arrange to use a dense address
range on a 64-bit machine.
The heap map is in bss. The assumption is that if
we don't touch the pages they won't be mapped in.
Also moved some duplicated memory allocation
code out of the OS-specific files.
R=r
CC=golang-dev
https://golang.org/cl/4118042
The fault was lucky: when it wasn't faulting it was silently
copying a word from some other block and later putting
that same word back. If some other goroutine had changed
that word of memory in the interim, too bad.
The ARM code was inconsistent about whether the
"argument frame" included the saved LR. Including it made
some things more regular but mostly just caused confusion
in the places where the regularity broke. Now the rule
reflects reality: argp is always a pointer to arguments,
never a saved link register.
Renamed struct fields to make meaning clearer.
Running ARM in QEMU, package time's gotest:
* before: 27/58 failed
* after: 0/50
R=r, r2
CC=golang-dev
https://golang.org/cl/3993041
I missed that environment is used during runtime setup,
well before go init() functions run. Implemented os-dependent
runtime.goenvs functions to allow for different unix, plan9 and
windows versions of environment discovery.
R=rsc, paulzhol
CC=golang-dev
https://golang.org/cl/3787046
cc: same
runtime: test cc alignment (required moving #define of offsetof to runtime.h)
fix bug260
Fixes#482.
Fixes#609.
R=ken2, r
CC=golang-dev
https://golang.org/cl/3563042
Formerly known as libcgo.
Almost no code here is changing; the diffs
are shown relative to the originals in libcgo.
R=r
CC=golang-dev
https://golang.org/cl/3420043
Prefix all external symbols in runtime by runtime·,
to avoid conflicts with possible symbols of the same
name in linked-in C libraries. The obvious conflicts
are printf, malloc, and free, but hide everything to
avoid future pain.
The symbols left alone are:
** known to cgo **
_cgo_free
_cgo_malloc
libcgo_thread_start
initcgo
ncgocall
** known to linker **
_rt0_$GOARCH
_rt0_$GOARCH_$GOOS
text
etext
data
end
pclntab
epclntab
symtab
esymtab
** known to C compiler **
_divv
_modv
_div64by32
etc (arch specific)
Tested on darwin/386, darwin/amd64, linux/386, linux/amd64.
Built (but not tested) for freebsd/386, freebsd/amd64, linux/arm, windows/386.
R=r, PeterGo
CC=golang-dev
https://golang.org/cl/2899041
Adds softfloat64 to generic runtime
(will be discarded by linker when unused)
and adds test for it. I used the test to check
the software code against amd64 hardware
and then check the software code against
the arm and its simulation of hardware.
The latter should have been a no-op (testing
against itself) but turned up a bug in 5c causing
the vlrt.c routines to miscompile.
These changes make the cmath, math,
and strconv tests pass without any special
accommodations for arm.
R=ken2
CC=golang-dev
https://golang.org/cl/2713042
No multiple processes/locks, managed to compile
and run a hello.go (with print not fmt). Also test/sieve.go
seems to run until 439 and stops with a
'throw: all goroutines are asleep - deadlock!'
- just like runtime/tiny.
based on Russ's suggestions at:
http://groups.google.com/group/comp.os.plan9/browse_thread/thread/cfda8b82535d2d68/243777a597ec1612
Build instructions:
cd src/pkg/runtime
make clean && GOOS=plan9 make install
this will build and install the runtime.
When linking with 8l, you should pass -s to suppress symbol
generation in the a.out, otherwise the generated executable will not run.
This is runtime only, the porting of the toolchain has already
been done: http://code.google.com/p/go-plan9/source/browse
in the plan9-quanstro branch.
R=rsc
CC=golang-dev
https://golang.org/cl/2273041
Old code was using recursion to traverse object graph.
New code uses an explicit stack, cutting the per-pointer
footprint to two words during the recursion and avoiding
the standard allocator and stack splitting code.
in test/garbage:
Reduces parser runtime by 2-3%
Reduces Peano runtime by 40%
Increases tree runtime by 4-5%
R=r
CC=golang-dev
https://golang.org/cl/2150042
Based on the observation that a great number of the types that
are copied or compared in interfaces, maps, and channels are
word-sized, this uses specialized copy and equality functions
for them that use a word instead of 4 or 8 bytes. Seems to yield
0-6% improvements in performance in the benchmarks I've run.
For example, with the regexp benchmarks:
Before:
regexp.BenchmarkLiteral 500000 3.26 µs/op
regexp.BenchmarkNotLiteral 100000 13.67 µs/op
regexp.BenchmarkMatchClass 100000 18.72 µs/op
regexp.BenchmarkMatchClass_InRange 100000 20.04 µs/op
regexp.BenchmarkReplaceAll 100000 27.85 µs/op
After:
regexp.BenchmarkLiteral 500000 3.11 µs/op
regexp.BenchmarkNotLiteral 200000 13.29 µs/op
regexp.BenchmarkMatchClass 100000 17.65 µs/op
regexp.BenchmarkMatchClass_InRange 100000 18.49 µs/op
regexp.BenchmarkReplaceAll 100000 26.34 µs/op
R=rsc
CC=golang-dev
https://golang.org/cl/1967047
Function to create a GoString with a known length so it can contain NUL
bytes anywhere in the string. Some C libraries have strings like this.
R=rsc
CC=golang-dev
https://golang.org/cl/2007042
These functions are used to call from a C function back to a
Go function. This only includes 386 support.
R=rsc
CC=golang-dev
https://golang.org/cl/834045
tested on linux/amd64, linux/386, linux/arm, darwin/amd64, darwin/386.
freebsd untested; will finish in a separate CL.
for now all the panics are errorStrings.
richer structures can be added as necessary
once the mechanism is shaked out.
R=r
CC=golang-dev
https://golang.org/cl/906041
* correct symbol table size
* do not reorder functions in output
* traceback
* signal handling
* use same code for go + defer
* handle leaf functions in symbol table
R=kaib, dpx
CC=golang-dev
https://golang.org/cl/884041
main semantic change is to enforce single argument to panic.
runtime: change to 1-argument panic.
use String method on argument if it has one.
R=ken2, r
CC=golang-dev
https://golang.org/cl/812043
(Thanks to ken and rsc for pointing this out)
rsc:
ken pointed out that there's a race in the new
one-lock-per-channel code. the issue is that
if one goroutine has gone to sleep doing
select {
case <-c1:
case <-c2:
}
and then two more goroutines try to send
on c1 and c2 simultaneously, the way that
the code makes sure only one wins is the
selgen field manipulation in dequeue:
// if sgp is stale, ignore it
if(sgp->selgen != sgp->g->selgen) {
//prints("INVALID PSEUDOG POINTER\n");
freesg(c, sgp);
goto loop;
}
// invalidate any others
sgp->g->selgen++;
but because the global lock is gone both
goroutines will be fiddling with sgp->g->selgen
at the same time.
This results in a 7% slowdown in the single threaded case for a
ping-pong microbenchmark.
Since the cas predominantly succeeds, adding a simple check first
didn't make any difference.
R=rsc
CC=golang-dev
https://golang.org/cl/180068
* add runtime sliceslice1 for x[lo:]
* remove runtime arraytoslice, rewriting &arr into arr[0:len(arr)].
* port cgen_inline into 8g, 5g.
* use native memmove in maps
R=ken2
https://golang.org/cl/157106
In thread.c, we need to cast to whatever the native
size of intptr is on the system, but we only have
uintptr available. They're the same size, but can't
do signed casts without this one :).
R=rsc
CC=golang-dev
https://golang.org/cl/156073
SELinux will cause mmap to fail when we request w+x memory unless the
user has configured their policies. We have a warning in make.bash,
but it's quite likely that the policy will be reset at some point and
then all their binaries start failing.
This patch prints a warning on Linux when mmap fails with EACCES.
R=rsc
CC=golang-dev
https://golang.org/cl/152086
now that all arguments are passed on the stack.
go/test: passes 89% (310/345)
R=rsc
APPROVED=rsc
DELTA=33 (13 added, 14 deleted, 6 changed)
OCL=36009
CL=36022
because they are in package runtime.
another step to enforcing package boundaries.
R=r
DELTA=732 (114 added, 93 deleted, 525 changed)
OCL=35811
CL=35824
* in 6l, -K already meant check for stack underflow.
add -KK to mean double-check stack overflows
even in nosplit functions.
* comment out print locks; they deadlock too easily
but are still useful to put back for special occasions.
* let runcgo assembly switch to scheduler stack
without involving scheduler directly. because runcgo
gets called from matchmg, it is too hard to keep it
from being called on other stacks.
R=r
DELTA=94 (65 added, 18 deleted, 11 changed)
OCL=35591
CL=35604
better mach binaries.
cgo working on darwin+linux amd64+386.
eliminated context switches - pi is 30x faster.
add libcgo to build.
on snow leopard:
- non-cgo binaries work; all tests pass.
- cgo binaries work on amd64 but not 386.
R=r
DELTA=2031 (1316 added, 626 deleted, 89 changed)
OCL=35264
CL=35304
* change ldt0setup to set GS itself; nacl won't let us do it.
* change breakpoint to INT $3 so 8l can translate to HLT for nacl.
* panic if closure is needed on nacl.
* do not try to access symbol table on nacl.
* mmap in 64kB chunks.
nacl support:
* system calls, threading, locks.
R=r
DELTA=365 (357 added, 5 deleted, 3 changed)
OCL=34880
CL=34906
runtime package for use by debugger,
which needs to make sure that all ptrace calls
about a given pid come from the same thread.
R=r
DELTA=175 (90 added, 63 deleted, 22 changed)
OCL=31546
CL=31558
* keep coherent SP/PC in gobuf
(i.e., SP that would be in use at that PC)
* gogocall replaces setspgoto,
should work better in presence of link registers
* delete unused system calls
only amd64; 386 is now broken
R=r
DELTA=548 (183 added, 183 deleted, 182 changed)
OCL=30381
CL=30442
not observed: do not use malloc to allocate stacks
during garbage collection, because it would make the
malloc data structures change underfoot.
R=r
DELTA=6 (3 added, 0 deleted, 3 changed)
OCL=30323
CL=30326
