| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Overhaul the mangling scheme to avoid ambiguities if the package path
contains a dot. Instead of using dot both to separate components and
to mangle characters, use dot only to separate components and use
underscore to mangle characters.
For golang/go#41862
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/271726
|
|
As we move toward the Go 1.7 garbage collector, it's essential that all
allocation of values that can contain Go pointers be done using the
correct type descriptor. That is simplest if we do all such allocation
in Go code. This rewrites the code that converts from a Go type to a
libffi CIF into Go.
Reviewed-on: https://go-review.googlesource.com/33353
From-SVN: r242578
|
|
PR go/72814
runtime: treat zero-sized result value as void
Change the FFI interface to treat a call to a function that returns a
zero-sized result as a call to a function that returns void.
This is part of the fix for https://gcc.gnu.org/PR72814. On 32-bit
SPARC systems, a call to a function that returns a non-zero-sized struct
is followed by an unimp instruction that describes the size of the
struct. The function returns to the address after the unimp
instruction. The libffi library can not represent a zero-sized struct,
so we wind up treating it as a 1-byte struct. Thus in that case libffi
calls the function with an unimp instruction, but the function does not
adjust the return address. The result is that the program attempts to
execute the unimp instruction, causing a crash.
This is part of a change that fixes the crash by treating all functions
that return zero bytes as functions that return void.
Reviewed-on: https://go-review.googlesource.com/25585
* go-gcc.cc (Gcc_backend::function_type): If the return type is
zero bytes, treat the function as returning void.
(return_statement): If the return type is zero bytes, don't
actually return any values.
From-SVN: r239252
|
|
All supported libgo 386 targets now have complex support in
libffi.
From Uros Bizjak.
From-SVN: r219877
|
|
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
|
|
A recent libffi upgrade caused the reflect test to fail on
386. The problem case is a function that returns an empty
struct--a struct with no fields. The libffi library does not
recognize the existence of empty structs, presumably since
they can't happen in C. To work around this, the Go interface
to the libffi library changes an empty struct to void. This
normally works fine, but with the new libffi upgrade it fails
for a function that returns an empty struct. On 386 a
function that returns a struct is expected to pop the hidden
pointer when it returns. So when we convert an empty struct
to void, libffi is calling a function that pops the hidden
pointer but does not expect that to happen.
In the older version of libffi, this didn't matter, because
the libffi code for 386 used a frame pointer, so the fact that
the stack pointer was wonky when the function returned was
ignored as the stack pointer was immediately replaced by the
saved frame pointer. In the newer version of libffi, the 386
code is more efficient and does not use a frame pointer, and
therefore it matters whether libffi expects the function to
pop the hidden pointer or not.
This patch changes libgo to convert an empty to a struct with
a single field of type void. This seems to be enough to get
the test cases working again.
Of course the real fix would be to change libffi to handle
empty types, but as libffi uses size == 0 as a marker for an
uninitialized type, that would be a non-trivial change.
From-SVN: r219701
|
|
Keep using the existing 386 and amd64 code on those archs,
since it is more efficient.
From-SVN: r212853
|
