This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gofrontend-dev] Re: [PATCH 00/13] Go closures, libffi, and the static chain


On Thu, Nov 6, 2014 at 11:38 PM, Richard Henderson <rth@redhat.com> wrote:
> On 11/06/2014 06:45 PM, Ian Taylor wrote:
>> On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson <rth@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 produces.
>>>
>>> I'm pretty sure that there are no dynamically linked Go calls that require the
>>> static chain.  They're used for closures, which are either fully indirect from
>>> a different translation unit, or locally bound closures through which the
>>> optimizer has seen the construction, and optimized to a direct call.
>>>
>>> Ian, have I missed a case where a closure could wind up with a direct call to a
>>> lazy bound function?
>>
>> I think you've covered all the cases.  The closure value is only
>> required when calling a nested function.  There is no way to refer
>> directly to a nested function defined in a different shared library.
>> The only way you can get such a reference is if some function in that
>> shared library returns it.
>
> Sorry, I wasn't clear.  I know nested functions must be local.
>
> I'm asking about Go closures, supposing we go ahead with the change to
> make them use the static chain register.

I think we're saying the same thing.

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 be empty
and it will never be used.  The indirect call will set the closure
value in the static chain register, but the register will not be used
by the function being called.

> I'm merely pretty sure that calling a closure is either fully indirect
> or local direct.

Yes.

> Certainly there are cases in the testsuite where -O3 is able to look
> through the creation of a closure and have a direct call to the function.
>
> Given that closures are custom created for the data at the creation
> site, it seems unlikely that the optimizer could look through that and
> come up with a dynamically bound function.

Yes.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]