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
This patch fixes a rare but serious bug. The Go garbage
collector only examines Go stacks. When Go code calls a
function that is not written in Go, it first calls
syscall.Entersyscall. Entersyscall records the position of
the Go stack pointer and saves a copy of all the registers.
If the garbage collector runs while the thread is executing
the non-Go code, the garbage collector fetches the stack
pointer and registers from the saved location.
Entersyscall saves the registers using the getcontext
function. Unfortunately I didn't consider the possibility
that Entersyscall might itself change a register before
calling getcontext. This only matters for callee-saved
registers, as caller-saved registers would be visible on the
saved stack. And it only matters if Entersyscall is compiled
to save and modify a callee-saved register before it calls
getcontext. And it only matters if a garbage collection
occurs while the non-Go code is executing. And it only
matters if the only copy of a valid Go pointer happens to be
in the callee-saved register when Entersyscall is called.
When all those conditions are true, the Go pointer might get
collected incorrectly, leading to memory corruption.
This patch tries to avoid the problem by splitting
Entersyscall into two functions. The first is a simple
function that just calls getcontext and then calls the rest of
Entersyscall. This should fix the problem, provided the
simple Entersyscall function does not itself modify any
callee-saved registers before calling getcontext. That seems
to be true on the systems I checked. But since the argument
to getcontext is an offset from a TLS variable, it won't be
true on a system which needs to save callee-saved registers in
order to get the address of a TLS variable. I don't know why
any system would work that way, but I don't know how to rule
it out. I think that on any such system this will have to be
implemented in assembler. I can't put the ucontext_t
structure on the stack, because this function can not split
stacks, and the ucontext_t structure is large enough that it
could cause a stack overflow.
From-SVN: r208390
This changes the compiler and runtime to not pass a closure
value as the last argument, but to instead pass it via
__go_set_closure and retrieve it via __go_get_closure. This
eliminates the need for function descriptor wrapper functions.
It will make it possible to retrieve the closure value in a
reflect.MakeFunc function.
From-SVN: r202233
