This is the mail archive of the 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 01/25/2017 05:22 PM, Carlos O'Donell wrote:
On 01/25/2017 11:59 AM, Jeff Law wrote:
On 01/25/2017 09:54 AM, Rich Felker wrote:
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

That's not a conforming C implementation. C specifies working
comparison of function pointers.
This was all hidden by the compiler. At the C level you just compared
the function pointers.

We do the same for 32-bit hppa on Linux (along with a host of other weird

Honestly I don't know why they didn't just bite the bullet and do unique
OPDs like POWER and make the comparison simpler.
I could ask Cary :-) There was also a lot of hair for MPE support in the 32bit SOM ABI, which may have played a role. I don't recall if they ever shipped MPE running on PAs, but it certainly influenced the toolchain decisions they made.


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