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_C
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 sh
On Fri, Dec 12, 2014 at 10:49 AM, Richard Henderson 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
> gccgo -shar
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
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 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 https://gcc.gnu.org/ml/gcc-patches/201
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 c
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 linke
On 12/11/2014 01:06 AM, Dominik Vogt wrote:
> reflect.call
> ../../../libgo/runtime/go-reflect-call.c:216
> reflect.call.N13_reflect.Value
>
> GCCDIR/build-go-closure/x86_64-unknown-linux-gnu/libgo/gotest30365/test/value.go:579
> reflect.Call.N13_reflect.Value
>
> GCCDIR/build-g
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 calli
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 destro
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 contents of r0 (static
> chain register) eventually causing a
On Fri, Oct 10, 2014 at 01:42:40PM -0700, Richard Henderson wrote:
> The background here is my thread from last week[1], and Ian's reply[2],
> wherein he rightly points out that not needing to play games with
> mmap in order to implement closures for Go is a strong reason to
> continue using custom
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 alwa
On Thu, Nov 6, 2014 at 11:38 PM, Richard Henderson wrote:
> On 11/06/2014 06:45 PM, Ian Taylor wrote:
>> On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson wrote:
>>>
>>> That said, this *may* not actually be a problem. It's not the direct
>>> (possibly
>>> lazy bound) call into libffi that need
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 r
On 11/06/2014 06:45 PM, Ian Taylor wrote:
> On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson 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 produc
On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson 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 produces.
>
> I'm
On 11/06/2014 02:10 PM, Lynn A. Boger wrote:
> Aren't there cases where the static chain register is needed? How does that
> work if it could be trashed on a plt call?
No. At the moment the static chain is only used for nested functions, which
are local to the translation unit, and are therefore
Aren't there cases where the static chain register is needed? How does
that work if it could be trashed on a plt call?
On 11/06/2014 06:48 AM, Alan Modra wrote:
On Thu, Nov 06, 2014 at 07:59:16AM +0100, Richard Henderson wrote:
I haven't done powerpc yet. If you'd like to help, I'd be deligh
On 11/06/2014 01:48 PM, Alan Modra wrote:
> On Thu, Nov 06, 2014 at 07:59:16AM +0100, Richard Henderson wrote:
>> I haven't done powerpc yet. If you'd like to help, I'd be delighted.
>
> I was going to say that it doesn't look too difficult, but then I
> noticed we have a problem. PowerPC uses r
On Thu, Nov 06, 2014 at 07:59:16AM +0100, Richard Henderson wrote:
> I haven't done powerpc yet. If you'd like to help, I'd be delighted.
I was going to say that it doesn't look too difficult, but then I
noticed we have a problem. PowerPC uses r11 as the static chain,
a register that is allowed
On 11/05/2014 10:33 PM, Lynn A. Boger wrote:
> What about the libffi changes that are needed to make this work on other
> platforms, like PowerPC?
I've been working my way through the currently supported libgo targets on
libffi-discuss, hoping to get them in upstream libffi before importing to gcc
What about the libffi changes that are needed to make this work on other
platforms, like PowerPC?
On 10/10/2014 03:42 PM, Richard Henderson wrote:
Pardon the wide distribution, the obvious hacks, and the failure
to properly split up the largest of the libffi patches.
The background here is my
On Fri, Oct 10, 2014 at 1:42 PM, Richard Henderson wrote:
>
> So instead I thought about how I'd add some support for Go directly
> into libffi. After all, we've got some custom code in libffi for
> Java, why couldn't Go have the same treatment?
>
> The stickler, as far as I could see, is __go_se
Pardon the wide distribution, the obvious hacks, and the failure
to properly split up the largest of the libffi patches.
The background here is my thread from last week[1], and Ian's reply[2],
wherein he rightly points out that not needing to play games with
mmap in order to implement closures for
26 matches
Mail list logo
