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

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

[Carlos O'Donell]

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.


> Diff:
> ---
>  sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c b/sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c
> index 8821218..4e4c2a2 100644
> --- a/sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c
> +++ b/sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c
> @@ -59,7 +59,7 @@ __get_clockfreq (void)
>       timebase        : 33333333
>       We search for this line and convert the number into an integer.  */
>    int fd = __open_nocancel ("/proc/cpuinfo", O_RDONLY);
> -  if (__glibc_likely (fd != -1))
> +  if (__glibc_unlikely (fd == -1))
>      return result;
>  
>    /* The timebase will be in the 1st 1024 bytes for systems with up
> 


-- 
Cheers,
Carlos.

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

[Adhemerval Zanella]

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.

> 
>> Diff:
>> ---
>>  sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c b/sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c
>> index 8821218..4e4c2a2 100644
>> --- a/sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c
>> +++ b/sysdeps/unix/sysv/linux/powerpc/get_clockfreq.c
>> @@ -59,7 +59,7 @@ __get_clock freq (void)
>>       timebase        : 33333333
>>       We search for this line and convert the number into an integer.  */
>>    int fd = __open_nocancel ("/proc/cpuinfo", O_RDONLY);
>> -  if (__glibc_likely (fd != -1))
>> +  if (__glibc_unlikely (fd == -1))
>>      return result;
>>  
>>    /* The timebase will be in the 1st 1024 bytes for systems with up
>>
> 
> 

Re: [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).