On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson <r...@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
