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 Fri, Nov 07, 2014 at 08:06:52AM -0800, Ian Taylor wrote:
> 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.

Good, this was something I was still worried about, because the mere
fact that a call is indirect doesn't guarantee it won't hit a plt
stub.  Many ABIs define the address of a non-local function in an
executable to be the address of the plt stub code for that function.
So it is quite possible for an indirect call to bounce through a plt
stub.  Various linker optimisations make this fairly uncommon, for
instance the GNU powerpc linkers won't do this unless the function
address is taken in the executable by non-PIC (see
pointer_equality_needed in BFD code).

-- 
Alan Modra
Australia Development Lab, IBM


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