On Fri, Dec 12, 2014 at 10:14:21AM -0800, Richard Henderson wrote:
On 12/12/2014 04:06 AM, Dominik Vogt wrote:
I'm not sure I've posted the missing patch anywhere yet, so it's
attached to this message. At the moment it enables
FFI_TYPE_COMPLEX only for s390[x], but eventually this should
On 12/15/2014 03:42 AM, Dominik Vogt wrote:
On Fri, Dec 12, 2014 at 10:14:21AM -0800, Richard Henderson wrote:
On 12/12/2014 04:06 AM, Dominik Vogt wrote:
I'm not sure I've posted the missing patch anywhere yet, so it's
attached to this message. At the moment it enables
FFI_TYPE_COMPLEX only
On Thu, Dec 11, 2014 at 11:56:00AM -0800, Richard Henderson wrote:
On 12/11/2014 04:25 AM, Dominik Vogt wrote:
Update: If I disable the custom s390x code and switch to the
implementation just using libffi for reflection calls, the same
crash occurs with the testing/quick libgo test case.
On Thu, Dec 11, 2014 at 07:51:44PM +1030, Alan Modra wrote:
I was worried about exactly the same problem on powerpc with r11
being used for the static chain and also destroyed in linkage stubs.
It turns out we don't traverse any linkage stubs.
See
On 12/12/2014 04:06 AM, Dominik Vogt wrote:
I'm not sure I've posted the missing patch anywhere yet, so it's
attached to this message. At the moment it enables
FFI_TYPE_COMPLEX only for s390[x], but eventually this should be
used unconditionally.
Thanks for that. I'd been meaning to get
On 12/12/2014 05:57 AM, Dominik Vogt wrote:
On Thu, Dec 11, 2014 at 07:51:44PM +1030, Alan Modra wrote:
I was worried about exactly the same problem on powerpc with r11
being used for the static chain and also destroyed in linkage stubs.
It turns out we don't traverse any linkage stubs.
See
On Fri, Dec 12, 2014 at 10:49 AM, Richard Henderson r...@redhat.com wrote:
Oh, that's interesting. You've found a bug in the x86_64 linking:
gccgo -g3 -O3 -Wall -Werror -c -fPIC q.go -o q.o
gccgo -shared -Wl,-soname,libq.so -o libq.so q.o
gccgo -g3 -O3 -Wall -Werror -c -fPIC p.go -o p.o
On Thu, Dec 11, 2014 at 07:51:44PM +1030, Alan Modra wrote:
On Thu, Dec 11, 2014 at 10:06:23AM +0100, Dominik Vogt wrote:
On s390x, the static chain register cannot be used for passing the
Go closure pointer to a function: According to the Abi, the
dynamic linker is allowed to destroy the
On Thu, Dec 11, 2014 at 11:31:06AM +0100, Dominik Vogt wrote:
Just to make this clear: It's not something that *might* happen.
It *does* happen on s390[x] which does not use libffi but the hand
written code in makefunc_s390.S and makefuncgo_s390[x].go.
The same may not happen when calling
On 12/11/2014 04:25 AM, Dominik Vogt wrote:
Update: If I disable the custom s390x code and switch to the
implementation just using libffi for reflection calls, the same
crash occurs with the testing/quick libgo test case. The called
function sees a bogus value written by the synamic linker
I worked on what I suspect is similar stuff.
I ran into the problem..pardon me if my terminology is wrong..PLT thunks for
nested functions trashed registers that were in use. My solution was to mark
them hidden or whatever is the term for not replaceable...also not exported
but I recall not
On Thu, Nov 6, 2014 at 11:38 PM, Richard Henderson r...@redhat.com wrote:
On 11/06/2014 06:45 PM, Ian Taylor wrote:
On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson r...@redhat.com wrote:
That said, this *may* not actually be a problem. It's not the direct
(possibly
lazy bound) call into
On Fri, Nov 07, 2014 at 08:06:52AM -0800, Ian Taylor wrote:
Closures exist only for nested functions and for functions created by
reflect.MakeFunc and friends.
Storing a top-level function into a variable will give you something
that looks like it has a closure, but the closure will always
On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson r...@redhat.com wrote:
That said, this *may* not actually be a problem. It's not the direct
(possibly
lazy bound) call into libffi that needs a static chain, it's the indirect call
that libffi produces. And the indirect calls that Go
On 11/06/2014 06:45 PM, Ian Taylor wrote:
On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson r...@redhat.com wrote:
That said, this *may* not actually be a problem. It's not the direct
(possibly
lazy bound) call into libffi that needs a static chain, it's the indirect
call
that libffi
15 matches
Mail list logo
