I typoed the argument passed to getcontext in getTraceback, and the
error was hidden by ucontext_arg. This would have been caught by some
of the runtime package tests, but we don't run most of them because
they rely on `go build`, and the go tool is not available while
running the libgo testsuite. We should fix the libgo testsuite,
somehow, so that they run.
Reviewed-on: https://go-review.googlesource.com/35837
From-SVN: r244946
Some fixes that permit misc/cgo/test in the master gc repository to
pass using the current gccgo.
Install testing/internal/testdeps.gox; it is needed by `go test`.
Export runtime.lockedOSThread to enable calling via go:linkname; it is
used by misc/cgo/test.
Loop on EAGAIN when creating a new thread; this is what the gc code
does, and misc/cgo/test tests that it works.
Reviewed-on: https://go-review.googlesource.com/35479
From-SVN: r244733
Compiler changes:
* Change map assignment to use mapassign and assign value directly.
* Change string iteration to use decoderune, faster for ASCII strings.
* Change makeslice to take int, and use makeslice64 for larger values.
* Add new noverflow field to hmap struct used for maps.
Unresolved problems, to be fixed later:
* Commented out test in go/types/sizes_test.go that doesn't compile.
* Commented out reflect.TestStructOf test for padding after zero-sized field.
Reviewed-on: https://go-review.googlesource.com/35231
gotools/:
Updates for Go 1.8rc1.
* Makefile.am (go_cmd_go_files): Add bug.go.
(s-zdefaultcc): Write defaultPkgConfig.
* Makefile.in: Rebuild.
From-SVN: r244456
I looked at a diff of proc.go between Go 1.7 and gccgo, and copied
over all the easy stuff.
Reviewed-on: https://go-review.googlesource.com/35090
From-SVN: r244291
This started by moving procresize from C to Go so that we can pass the
right type to the memory allocator when allocating a p, which forced
the gomaxprocs variable to move from C to Go, and everything else
followed from that.
Reviewed-on: https://go-review.googlesource.com/34916
From-SVN: r244236
Remove support for _cgo_allocate. It was removed from the gc
toolchain in Go 1.5, so it is unlikely that anybody is trying to use it.
Reviewed-on: https://go-review.googlesource.com/34557
From-SVN: r243805
Rewrite the AES hashing code from gc assembler to C code using
intrinsics. The resulting code generates the same hash code for the
same input as the gc code--that doesn't matter as such, but testing it
ensures that the C code does something useful.
Also change mips64pe32le to mips64p32le in configure script--noticed
during CL review.
Reviewed-on: https://go-review.googlesource.com/34022
From-SVN: r243445
The actual stack unwind code is still in C, but the rest of the code,
notably all the memory allocation, is now in Go. The names are changed
to the names used in the Go 1.7 runtime, but the code is necessarily
somewhat different.
The __go_makefunc_can_recover function is dropped, as the uses of it
were removed in https://golang.org/cl/198770044.
Reviewed-on: https://go-review.googlesource.com/33414
From-SVN: r242715
This doesn't change any actual code, it just starts using the Go
definition of the schedt type and the sched variable rather than the C
definitions.
The schedt type is tweaked slightly for gccgo. We aren't going to
release goroutine stacks, so we don't need separate gfreeStack and
gfreeNostack lists. We only have one size of defer function, so we
don't need a list of 5 different pools.
Reviewed-on: https://go-review.googlesource.com/33364
From-SVN: r242600
A step toward eliminating goc2c.
Drop the exported parfor code; it was needed for tests in the past, but
no longer is. The Go 1.7 runtime no longer uses parfor.
Reviewed-on: https://go-review.googlesource.com/33324
From-SVN: r242509
Add a little shell script to auto-generate runtime.sigtable from the
known signal names.
Force the main package to always import the runtime package. Otherwise
some runtime package global variables may never be initialized.
Set the syscallsp and syscallpc fields of g when entering a syscall, so
that the runtime package knows when a g is executing a syscall.
Fix runtime.funcPC to avoid dead store elimination of the interface
value when the function is inlined.
Reviewed-on: https://go-review.googlesource.com/33025
From-SVN: r242060
While testing a patch on Solaris, which does not support split-stack, I
ran across a bug in the handling of caller-saved registers for the
garbage collector. For non-split-stack systems, runtime_mcall is
responsible for saving all caller-saved registers on the stack so that
the GC stack scan will see them. It does this by calling
__builtin_unwind_init and setting the g's gcnextsp field to point to the
current stack. The garbage collector then scans the stack from gcnextsp
to the top of stack.
Unfortunately, the code was setting gcnextsp to point to runtime_mcall's
argument, which meant that even though runtime_mcall was careful to
store all caller-saved registers on the stack, the GC never saw them.
This is, of course, only a problem if a value lives only in a
caller-saved register, and not anywhere else on the stack or heap. And
it is only a problem if that caller-saved register manages to make it
all the way down to runtime_mcall without being saved by any function on
the way. This is moderately unlikely but it turns out that the recent
changes to keep values on the stack when compiling the runtime package
caused it to happen for the local variable `s` in `notifyListWait` in
runtime/sema.go. That function calls goparkunlock which is simple
enough to not require all registers, and itself calls runtime_mcall. So
it was possible for `s` to be released by the GC before the goroutine
returned from goparkunlock, which eventually caused a dangling pointer
to be passed to releaseSudog.
This is not a problem on split-stack systems, which use
__splitstack_get_context, which saves a stack pointer low enough on the
stack to scan the registers saved by runtime_mcall.
Reviewed-on: https://go-review.googlesource.com/31323
From-SVN: r241304
While we're at it, update the runtime/debug package, and start running
its testsuite by default. I'm not sure why runtime/debug was not
previously updated to 1.7. Doing that led me to fix some minor aspects
of runtime.Stack and the C function runtime/debug.readGCStats.
Reviewed-on: https://go-review.googlesource.com/31251
From-SVN: r241261
Also create a gccgo version of some of the traceback code in
traceback_gccgo.go, replacing some code currently in C.
This required modifying the compiler so that when compiling the runtime
package a slice expression does not cause a local array variable to
escape to the heap.
Reviewed-on: https://go-review.googlesource.com/31230
From-SVN: r241189
This replaces runtime/cpuprof.goc with go/runtime/cpuprof.go and adjusts
the supporting code in runtime/proc.c.
This adds another case where the compiler needs to avoid heap allocation
in the runtime package: when evaluating a method expression into a
closure. Implementing this required moving the relevant code from
do_get_backend to do_flatten, so that I could easily add a temporary
variable. Doing that let me get rid of Bound_method_expression::do_lower.
Reviewed-on: https://go-review.googlesource.com/31050
From-SVN: r241163
This replaces mem.go and the C runtime_ReadMemStats function with the Go
1.7 mstats.go.
The GCStats code is commented out for now. The corresponding gccgo code
is in runtime/mgc0.c.
The variables memstats and worldsema are shared between the Go code and
the C code, but are not exported. To make this work, add temporary
accessor functions acquireWorldsema, releaseWorldsema, getMstats (the
latter known as mstats in the C code).
Check the preemptoff field of m when allocating and when considering
whether to start a GC. This works with the new stopTheWorld and
startTheWorld functions in Go, which are essentially the Go 1.7
versions.
Change the compiler to stack allocate closures when compiling the
runtime package. Within the runtime packages closures do not escape.
This is similar to what the gc compiler does, except that the gc
compiler, when compiling the runtime package, gives an error if escape
analysis shows that a closure does escape. I added this here because
the Go version of ReadMemStats calls systemstack with a closure, and
having that allocate memory was causing some tests that measure memory
allocations to fail.
Reviewed-on: https://go-review.googlesource.com/30972
From-SVN: r241124
This triggered a check in releaseSudog that g.param not nil, because
libgo uses the param field when starting a goroutine. Fixed by clearing
g->param in kickoff in proc.c.
Reviewed-on: https://go-review.googlesource.com/30951
From-SVN: r241067
Update the compiler to use the new names. Add calls to printlock and
printunlock around print statements. Move expression evaluation before
the call to printlock. Update g's writebuf field to a slice, and adjust
C code accordingly.
Reviewed-on: https://go-review.googlesource.com/30717
From-SVN: r240956
Change the compiler to use the new routines. Drop the separation of
small and large values when sending on a channel. Allocate the select
struct on the stack. Remove the old C implementation of channels. Adjust
the garbage collector for the new data structure.
Bring in part of the tracing code, enough for the channel code to call.
Bump the permitted number of allocations in one of the tests in
context_test.go. The difference is that now receiving from a channel
allocates a sudog, which the C code used to simply put on the
stack. This will be somewhat better when we port proc.go.
Reviewed-on: https://go-review.googlesource.com/30714
From-SVN: r240941
Remove the old locking code written in C.
Add a shell script mkrsysinfo.sh to generate the runtime_sysinfo.go
file, so that we can get Go copies of the system time structures and
other types.
Tweak the compiler so that when compiling the runtime package the
address operator does not cause local variables to escape. When the gc
compiler compiles the runtime, an escaping local variable is treated as
an error. We should implement that, instead of this change, when escape
analysis is turned on.
Tweak the compiler so that the generated C header does not include names
that start with an underscore followed by a non-upper-case letter,
except for the special cases of _defer and _panic. Otherwise we
translate C types to Go in runtime_sysinfo.go and then generate those Go
types back as C types in runtime.inc, which is useless and painful for
the C code.
Change entersyscall and friends to take a dummy argument, as the gc
versions do, to simplify calls from the shared code.
Reviewed-on: https://go-review.googlesource.com/30079
From-SVN: r240657
This change removes the gccgo-specific hashmap code and replaces it with
the hashmap code from the Go 1.7 runtime. The Go 1.7 hashmap code is
more efficient, does a better job on details like when to update a key,
and provides some support against denial-of-service attacks.
The compiler is changed to call the new hashmap functions instead of the
old ones.
The compiler now tracks which types are reflexive and which require
updating when used as a map key, and records the information in map type
descriptors.
Map_index_expression is simplified. The special case for a map index on
the right hand side of a tuple expression has been unnecessary for some
time, and is removed. The support for specially marking a map index as
an lvalue is removed, in favor of lowering an assignment to a map index
into a function call. The long-obsolete support for a map index of a
pointer to a map is removed.
The __go_new_map_big function (known to the compiler as
Runtime::MAKEMAPBIG) is no longer needed, as the new runtime.makemap
function takes an int64 hint argument.
The old map descriptor type and supporting expression is removed.
The compiler was still supporting the long-obsolete syntax `m[k] = 0,
false` to delete a value from a map. That is now removed, requiring a
change to one of the gccgo-specific tests.
The builtin len function applied to a map or channel p is now compiled
as `p == nil ? 0 : *(*int)(p)`. The __go_chan_len function (known to
the compiler as Runtime::CHAN_LEN) is removed.
Support for a shared zero value for maps to large value types is
introduced, along the lines of the gc compiler. The zero value is
handled as a common variable.
The hash function is changed to take a seed argument, changing the
runtime hash functions and the compiler-generated hash functions.
Unlike the gc compiler, both the hash and equal functions continue to
take the type length.
Types that can not be compared now store nil for the hash and equal
functions, rather than pointing to functions that throw. Interface hash
and comparison functions now check explicitly for nil. This matches the
gc compiler and permits a simple implementation for ismapkey.
The compiler is changed to permit marking struct and array types as
incomparable, meaning that they have no hash or equal function. We use
this for thunk types, removing the existing special code to avoid
generating hash/equal functions for them.
The C runtime code adds memclr, memequal, and memmove functions.
The hashmap code uses go:linkname comments to make the functions
visible, as otherwise the compiler would discard them.
The hashmap code comments out the unused reference to the address of the
first parameter in the race code, as otherwise the compiler thinks that
the parameter escapes and copies it onto the heap. This is probably not
needed when we enable escape analysis.
Several runtime map tests that ere previously skipped for gccgo are now
run.
The Go runtime picks up type kind information and stubs. The type kind
information causes the generated runtime header file to define some
constants, including `empty`, and the C code is adjusted accordingly.
A Go-callable version of runtime.throw, that takes a Go string, is
added to be called from the hashmap code.
Reviewed-on: https://go-review.googlesource.com/29447
* go.go-torture/execute/map-1.go: Replace old map deletion syntax
with call to builtin delete function.
From-SVN: r240334
PR go/77642
runtime: pass correct type to __splitstack_find
The code was passing uintptr* to a function that expected size_t*.
Based on patch by Andreas Krebbel.
Fixes GCC PR 77642.
Reviewed-on: https://go-review.googlesource.com/29433
From-SVN: r240275
The definition and most uses of MAKECONTEXT_STACK_TOP were removed in
https://golang.org/cl/88660043, which removed support for Solaris 8/9.
One use of MAKECONTEXT_STACK_TOP was accidentally left in the source
code. Remove it now.
Reviewed-on: https://go-review.googlesource.com/28911
From-SVN: r240045
Some systems, such as ia64 and PPC, require that a ucontext_t pointer
passed to getcontext and friends be aligned to a 16-byte boundary.
Currently the ucontext_t fields in the g structure are defined in Go,
and Go has no way to ensure a 16-byte alignment for a struct field.
The fields are currently represented by an array of unsafe.Pointer.
Enforce the alignment by making the array larger, and picking an offset
into the array that is 16-byte aligned.
Reviewed-on: https://go-review.googlesource.com/28910
From-SVN: r240044
Use the new -fgo-c-header option to build a header file for the Go
runtime code in libgo/go/runtime, and use the new header file in the C
runtime code in libgo/runtime. This will ensure that the Go code and C
code share the same data structures as we convert the runtime from C to
Go.
The new file libgo/go/runtime/runtime2.go is copied from the Go 1.7
release, and then edited to remove unnecessary data structures and
modify others for use with libgo.
The new file libgo/go/runtime/mcache.go is an initial version of the
same files in the Go 1.7 release, and will be replaced by the Go 1.7
file when we convert to the new memory allocator.
The new file libgo/go/runtime/type.go describes the gccgo version of the
reflection data structures, and replaces the Go 1.7 runtime file which
describes the gc version of those structures.
Using the new header file means changing a number of struct fields to
use Go naming conventions (that is, no underscores) and to rename
constants to have a leading underscore so that they are not exported
from the Go package. These names were updated in the C code.
The C code was also changed to drop the thread-local variable m, as was
done some time ago in the gc sources. Now the m field is always
accessed using g->m, where g is the single remaining thread-local
variable. This in turn required some adjustments to set g->m correctly
in all cases.
Also pass the new -fgo-compiling-runtime option when compiling the
runtime package, although that option doesn't do anything yet.
Reviewed-on: https://go-review.googlesource.com/28051
From-SVN: r239872
This is a port of https://golang.org/cl/18150 to the gccgo runtime.
The previous behaviour of installing the signal handlers in a separate
thread meant that Go initialization raced with non-Go initialization if
the non-Go initialization also wanted to install signal handlers. Make
installing signal handlers synchronous so that the process-wide behavior
is predictable.
Reviewed-on: https://go-review.googlesource.com/19494
From-SVN: r233393
PR go/69511
runtime: change G gcstack_size field to size_t
Because its address is passed to __splitstack_find, which expects size_t*.
From Dominik Vogt in GCC PR 69511.
Reviewed-on: https://go-review.googlesource.com/19429
From-SVN: r233260
When not using split stacks, libgo allocate large stacks for each
goroutine. On a 64-bit system, libgo allocates a maximum of 128G for
the Go heap, and allocates 4M for each stack. When the stacks are
allocated from the Go heap, the result is that a program can only create
32K goroutines, which is not enough for an active Go server. This patch
changes libgo to allocate the stacks using mmap directly, rather than
allocating them out of the Go heap. This change is only done for 64-bit
systems when not using split stacks. When using split stacks, the
stacks are allocated using mmap directly anyhow. On a 32-bit system,
there is no maximum size for the Go heap, or, rather, the maximum size
is the available address space anyhow.
Reviewed-on: https://go-review.googlesource.com/16531
From-SVN: r229636
Type descriptors picked up a zero field because the gc map
implementation used it. However, it's since been dropped by the gc
library. It was never used by gccgo. Drop it now in preparation for
upgrading to the Go 1.5 library.
Reviewed-on: https://go-review.googlesource.com/16486
From-SVN: r229546
Change the type descriptor hash and equal functions from C code pointers
to Go func values. This permits them to be set to a Go function
closure. This is in preparation for the Go 1.5, so that we can use a
closure for the hash/equal functions returned by the new reflect.ArrayOf
function.
Reviewed-on: https://go-review.googlesource.com/16485
From-SVN: r229541
These changes permit using the go tool from the upcoming Go
1.5 release with -buildmode=c-archive to build gccgo code into
an archive file that can be linked with a C program.
From-SVN: r222594
Change from using __go_set_closure to passing the closure
value in the static chain field. Uses new backend support for
setting the closure chain in a call from C via
__builtin_call_with_static_chain. Uses new support in libffi
for Go closures.
The old architecture specific support for reflect.MakeFunc is
removed, replaced by the libffi support.
All work done by Richard Henderson.
* go-gcc.cc (Gcc_backend::call_expression): Add chain_expr argument.
(Gcc_backend::static_chain_variable): New method.
From-SVN: r219776
Fix an unusual C to Go callback case. Newly created C threads
call into Go code, forcing the Go code to allocate new M and G
structures. While executing Go code, the stack is split. The
Go code then returns. Returning from a Go callback is treated
as entering a system call, so the G gcstack field is set to
point to the Go stack. In this case, though, we were called
from a newly created C thread, so we drop the extra M and G
structures. The C thread then exits.
Then a new C thread calls into Go code, reusing the previously
created M and G. The Go code requires a larger stack frame,
causing the old stack segment to be unmapped and a new stack
segment allocated. At this point the gcstack field is
pointing to the old stack segment.
Then a garbage collection occurs. The garbage collector sees
that the gcstack field is not nil, so it scans it as the first
stack segment. Unfortunately it points to memory that was
unmapped. So the program crashes.
The fix is simple: when handling extra G structures created
for callbacks from new C threads, clear the gcstack field.
From-SVN: r218699
We want to create goroutines with a small stack, at least on
systems where split stacks are supported. We don't need to
create threads with a small stack.
From-SVN: r216353
If the compiler inlines this function into kickoff, it may reuse
the TLS block address to load g. However, this is not necessarily
correct, as the call to g->entry in kickoff may cause the TLS
address to change. If the wrong value is loaded for g->status in
runtime_goexit, it may cause a runtime panic.
By marking the function as noinline we prevent the compiler from
reusing the TLS address.
From-SVN: r215484
PR go/61498
runtime: Always set gcnext_sp to pointer-aligned address.
The gcnext_sp field is only used on systems that do not use
split stacks. It marks the bottom of the stack for the
garbage collector. This change makes sure that the stack
bottom is always aligned to a pointer value.
Previously the garbage collector would align all the addresses
that it scanned, but it now expects them to be aligned before
scanning.
From-SVN: r211639
Ian Lance Taylor