[PATCH v2 0/2] Generic x86-64 CPU diagnostics dumper

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 07/12/23 09:36, Florian Weimer wrote:
>> * Adhemerval Zanella Netto:
>> 
>>> On 07/12/23 08:05, Florian Weimer wrote:
>>>> This is an unchanged repost after a rebase.
>>>>
>>>> I hope to get this integrated so that I can work on further CPU
>>>> compatibility diagnostics.  The intent behind those is to give
>>>> distributions better built-in tools to diagnose compatibility issues
>>>> after they incorporate CPU-specific optimizations.
>>>
>>> What I would expect from ld.so --list-diagnostics was to dump some
>>> relevant information used on ifunc and other optimizations selection, 
>>> with some meaningful text on the queried data from the kernel/CPU and 
>>> which function would be selected based on the obtained information.
>> 
>> We don't know what GCC (__builtin_cpu_supports etc.) bases its selection
>> on because it does not use the glibc interfaces.  Even if we restricted
>> this to other toolchain usage, we'd end up having to update it alongside
>> GCC changes that add more selection logic.  The generic dumper avoids
>> that.
>> 
>> Even inside glibc, we have logic that looks at CPUID data that is
>> currently not captured in the dumps.
>
> But my understanding is --list-diagnostics should be limited to own
> glibc selection; it does not make much sense to trying to sync with
> other interfaces (__builtin_cpu_supports) if there use a complete
> different selection interface.

I think we should consider the whole GNU toolchain, not just glibc.
Just as in other cases.

> Right, but currently  --list-diagnostics dumps around 100 lines related to 
> x86 on my system. Although some are straightforward (like cache size),
> some are really specific to implementation detail, like the 
> x86.cpu_features.features vs x86.cpu_features.preferred and the preferred
> fields description.

Yes, and those are required to diagnose issues with IFUNC selection and
other aspects of self-configuration.  Even so, the current dumps are
insufficient to trace how glibc comes up with the cache information for
sysconf.

They also do not cover asymmetric reporting across multiple cores.

> Also, such information can be queries either by accessing cpuid itself
> and/or with x86.h specific ABI (from x86.h).  My questioning is if this 
> really required to be on ld.so.

If we don't put it into a cross-architecture project, then we'll have to
teach everyone to use the appropriate tool for gathering such data on
every architecture.  This makes switching between architectures more
difficult.  I don't think we can get non-x86 CPU support into cpuid
<http://www.etallen.com/cpuid.html>.

Thanks,
Florian