This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: [gofrontend-dev] Re: [PATCH 00/13] Go closures, libffi, and the static chain
- From: Ian Taylor <iant at golang dot org>
- To: Richard Henderson <rth at redhat dot com>
- Cc: "Lynn A. Boger" <laboger at linux dot vnet dot ibm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, libffi-discuss at sourceware dot org, "gofrontend-dev at googlegroups dot com" <gofrontend-dev at googlegroups dot com>, ian at airs dot com
- Date: Thu, 6 Nov 2014 09:45:22 -0800
- Subject: Re: [gofrontend-dev] Re: [PATCH 00/13] Go closures, libffi, and the static chain
- Authentication-results: sourceware.org; auth=none
- References: <1412973773-3942-1-git-send-email-rth at redhat dot com> <545A97BA dot 3030507 at linux dot vnet dot ibm dot com> <545B1C44 dot 3000306 at redhat dot com> <20141106124838 dot GJ30857 at bubble dot grove dot modra dot org> <545B71D1 dot 1090406 at redhat dot com>
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
- References:
- [PATCH 00/13] Go closures, libffi, and the static chain
- Re: [PATCH 00/13] Go closures, libffi, and the static chain
- Re: [PATCH 00/13] Go closures, libffi, and the static chain
- Re: [PATCH 00/13] Go closures, libffi, and the static chain
- Re: [PATCH 00/13] Go closures, libffi, and the static chain