[RFC] Prevent tailcall optimizations of libdl functions

[Jeff Law]

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
>>>> purposes.
>>>
>>> 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
> things).
>
> 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.

Jeff