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

[Ian Taylor <iant@golang.org>]

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.

So we are OK assuming that when returning a nested function, which is
always known to be locally defined, we never return a reference to the
PLT, but always return a fully resolved function address.  That seems
like a plausible assumption, particularly since we should never need
to set up a PLT for a nested function, since it can never be called
directly from a different shared library.

Ian