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: V4 [PATCH] x86: Add <sys/platform/x86.h>


On Thu, Sep 20, 2018 at 5:43 AM, Florian Weimer <fweimer@redhat.com> wrote:
> * H. J. Lu:
>
>> On Thu, Sep 20, 2018 at 4:41 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> * H. J. Lu:
>>>
>>>> Add <sys/platform/x86.h> to provide an API to access x86 specific platform
>>>> features.  It makes raw and derived CPUID information available to
>>>> applications so that programmers can avoid complicated steps to retrieve
>>>> the same information with CPUID instructions.
>>>
>>> Sorry, I still think that this patch semantically depends on delayed
>>> IFUNC processing.

I don't believe this is an issue at all since new functions are in
ld.so.  Can you show this is a real issue with a testcase? I can
add it to my test.

>>> Furthermore, I strongly prefer a simplified interface, like:
>>>
>>>   enum {
>>>     X86_FEATURE_MMX,
>>>     X86_FEATURE_SSE,
>>>     X86_FEATURE_SSE2,
>>>     …
>>>     X86_FEATURE_AVX512F,
>>>     …
>>>   };
>>>
>>>   _Bool x86_feature_usable (int index) __attribute__ ((pure));
>>>
>>> Applications could then do something like this:
>>>
>>>   if (x86_feature_usable (X86_FEATURE_AVX512F))
>>>     return &__matmul_avx512f;
>>>
>>> I don't think there is value in exposing the CPUID data directly.  If
>>> programmers need it, they can use <cpuid.h> from GCC instead, without
>>> needing to worry how glibc populates its data structures.

There are several advantages of my approach:

1. When a new feature is added to previously reserved bit, the
program using the new feature will work with the older libc.so
whose CPUID data has the reserved bit.
2. We only need to add 2 small functions:

(gdb) disass x86_get_arch_feature
Dump of assembler code for function x86_get_arch_feature:
   0x0000000000017100 <+0>: xor    %eax,%eax
   0x0000000000017102 <+2>: cmp    $0x2,%edi
   0x0000000000017105 <+5>: ja     0x17117 <x86_get_arch_feature+23>
   0x0000000000017107 <+7>: mov    %edi,%edi
   0x0000000000017109 <+9>: lea    0x105f0(%rip),%rax        # 0x27700
<_rtld_local_ro>
   0x0000000000017110 <+16>: mov    0xb4(%rax,%rdi,4),%eax
   0x0000000000017117 <+23>: retq
End of assembler dump.
(gdb) disass x86_get_cpuid_registers
Dump of assembler code for function x86_get_cpuid_registers:
   0x00000000000170d0 <+0>: lea    0xc479(%rip),%rax        # 0x23550
<zero_cpuid_registers.8564>
   0x00000000000170d7 <+7>: cmp    $0x2,%edi
   0x00000000000170da <+10>: ja     0x170f0 <x86_get_cpuid_registers+32>
   0x00000000000170dc <+12>: mov    %edi,%edi
   0x00000000000170de <+14>: lea    0x1061b(%rip),%rax        #
0x27700 <_rtld_local_ro>
   0x00000000000170e5 <+21>: add    $0x7,%rdi
   0x00000000000170e9 <+25>: shl    $0x4,%rdi
   0x00000000000170ed <+29>: add    %rdi,%rax
   0x00000000000170f0 <+32>: retq
End of assembler dump.
(gdb)
3. Write CPUID program isn't easy.   You can try to write a program
to detect a CPUID feature to see what it takes.  I can't remember it
exactly without looking at glibc sources which I wrote.

>>
>> You have 2 concerns.  Which one is the primary concern?  Or
>> are both blockers for you?
>
> The design of the API is more important.
>
> We can implement delayed IFUNC processing later to support this feature
> (and others).

-- 
H.J.


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