[glibc/google/grte/v5-2.27/master] Fix sense of a test in the static-linking version of ppc get_clockfreq

[Adhemerval Zanella]

On 29/05/2019 10:33, Adhemerval Zanella wrote:
> 
> 
> On 18/05/2019 01:35, Carlos O'Donell wrote:
>> On 5/17/19 2:25 PM, Stan Shebs wrote:
>>> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=4791e4f773d060c1a37b27aac5b03cdfa9327afc
>>>
>>> commit 4791e4f773d060c1a37b27aac5b03cdfa9327afc
>>> Author: Stan Shebs <stanshebs@google.com>
>>> Date:   Fri May 17 12:25:19 2019 -0700
>>>
>>>     Fix sense of a test in the static-linking version of ppc get_clockfreq
>>>
>>
>> Stan,
>>
>> This looks like a fix that should go on master?
>>
>> Cheers,
>> Carlos.
>>
> 
> This in fact not required due 38cc11daa43b1, 77b6f553477, and 6e8ba7fd574.
> The __get_clock freq in fact is not really used in any recent kernel we
> support now, so its had been dead code for some time.
> 

Tulio has raised to my attention that get_timebase_freq.c has a similar issue.
Taking in consideration that BZ#19767 is at least fixed for powerpc, I think
best action would be to just remove INTERNAL_VSYSCALL_NO_SYSCALL_FALLBACK, 
check vdso pointer availability (assuming a kernel might be build without
vDSO support) and fallback to read /proc/cpuinfo in the case.

Something like:

uint64_t
__get_timebase_freq (void)
{ 
  hp_timing_t result = 0L;

  {
    /* The vDSO does not fail (it clear cr0.so on returning).  */
    __typeof (__vdso_get_tbfreq) vdsop = __vdso_get_tbfreq;
    PTR_DEMANGLE (vdsop)
    if (vdsop != NULL)
      return vdsop ();

    /* Fallback.  */
}

I also think mostly of INTERNAL_VSYSCALL_CALL_TYPE from powerpc sysdep could
just be removed since currently all vDSO symbol do not fail (so there is no 
need to actually check cr0.so value).