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
