This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: [RFC] Prevent tailcall optimizations of libdl functions


On Wed, Jan 25, 2017 at 08:42:44AM -0700, Jeff Law wrote:
> On 01/25/2017 07:32 AM, Florian Weimer wrote:
> >On 01/25/2017 03:08 PM, Rich Felker wrote:
> >
> >>FWIW this technique is non-conforming, at least for any standard
> >>functions it's used on, since it breaks pointer equality. A conforming
> >>program can evaluate p1==p2, where p1=dlsym is assigned in one dso and
> >>p2=dlsym is assigned in another, and must see equality on a conforming
> >>implementation. As such I think this hack needs to be removed from
> >>other functions like stat.
> >
> >Is there a specific requirement in POSIX to that effect, or is it an
> >accident as the result of how POSIX and ISO C interact?
> >
> >As far as I can tell, ISO C specifies function pointer equality by
> >saying that pointers compare equal iff they refer to the “same […]
> >function”, but the standard does not seem to define what makes two
> >functions the same.
> >
> >(But even if it is fully conforming or acceptable for other reasons, I
> >dislike the __dso_handle technique because it is too complex.)
> I've always interpreted it as "if I dereference the function
> pointers, do I get into the same function".  It's not proper
> standards language, but you get the basic idea.
> 
> The 32bit HPUX runtime had fptr descriptors which were not unique
> and were only used for a subset of indirect calls.  So you couldn't
> just compare function pointers.  You can do call into a special
> routine to compute/extract the actual address for comparison
> purposes.

That's not a conforming C implementation. C specifies working
comparison of function pointers.

Rich


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