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

[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.

> 
>> Instead, we are moving towards a generic tool that dumps a lot of 
>> information that is either not directly relevant or requires some 
>> other tool to post-process it. 
>>
>> This makes me wonder if it would be better to create a cpuid 
>> dumper/parser as a different program instead.
> 
> Some people can read these dumps directly (so far, I don't).  Even the
> limited, glibc-specific dumps we have today, which surprised me.> 
> Architecture-specific tools already exists, sure.  The downside is that
> every architecture needs a different tool, and we would need to educate
> users and support staff to request the appropriate data for each
> architecture.  I think in glibc, we are quite well-positioned to note
> what's important to include for each architecture (because we have such
> selection logic in glibc for the string functions) and provide an
> architecture-agnostic interface to capture the data for later analysis
> by someone with architecture-specific knowledge.

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.

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.