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


On Wed, Aug 29, 2018 at 8:41 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 08/29/2018 04:38 PM, H.J. Lu wrote:
>>
>> On Mon, Aug 20, 2018 at 1:54 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>
>>> On Mon, Aug 6, 2018 at 2:10 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>
>>>> Add <sys/platform/x86.h> to provide an API to access x86 specific
>>>> platform
>>>> features:
>>>>
>>>
>>> Here is the updated patch to rename x86  specific functions to x86_XXX.
>>>
>>
>> If there are no comments nor objections:
>>
>> https://sourceware.org/ml/libc-alpha/2018-08/msg00435.html
>>
>> I will check it in this Friday,
>
>
> I'm still concerned that the intended use of this facility is incompatible
> with BIND_NOW and other things that disable lazy binding.

The intended usage is similar to using CPUID instruction to detect CPU features.

> The manual also needs to explain how to use these facilities for feature
> detection.  I assume that just looking at (for example) HAS_CPU_FEATURE
> (AVX512F) will give wrong results.  If this is true, this seriously

Why should it give the wrong results?  Can you elaborate it?  Were you saying
that the result was different from using CPUID instruction directly?

> questions why we should expose these tests in a public header file.
>

<x86.h> provides a C interface to raw CPUID instruction.


-- 
H.J.


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