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: Jay <jay dot krell at cornell dot edu>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Ian Taylor <iant at golang dot org>, "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>" <libffi-discuss at sourceware dot org>, "gofrontend-dev at googlegroups dot com" <gofrontend-dev at googlegroups dot com>, "<ian at airs dot com>" <ian at airs dot com>
- Date: Fri, 7 Nov 2014 00:50:00 -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> <CAOyqgcWksQ=f3ekAPFyXcAVxWeyzzcNLKnHRqFkoYWOpNmcxUw at mail dot gmail dot com> <545C770A dot 9040100 at redhat dot com>
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 replaceable is more important.
- Jay
On 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'm merely pretty sure that calling a closure is either fully indirect
> or local direct.
>
> 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.
>
>
> r~
- 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
- Re: [gofrontend-dev] Re: [PATCH 00/13] Go closures, libffi, and the static chain
- Re: [gofrontend-dev] Re: [PATCH 00/13] Go closures, libffi, and the static chain