In 2b8023f733, I had to update the behavior of cpuid_tool to loop over all data.cpu_types items.
I did not realize since this change, it was not entering the loop for args with ident_required=0, because data.num_cpu_types was always 0, so print_info() was never called for such args.
In other words, args like --rdmsr or --cpuid did nothing due to this regression. This commit fix this regression.
* Set CMAKE_C_FLAGS_DEBUG to display warnings during build
CI workflows are reporting warnings. Adding more C flags here help to avoid that.
* Add new types
* Add set_cpu_affinity function
* Add cpu_identify_all function
* Add cpu_request_core_type function
* Add cpuid_get_all_raw_data, cpuid_serialize_all_raw_data and cpuid_deserialize_all_raw_data functions
* Detect hybrid architecture for Intel CPUs
* Update cpuid_tool to detect all CPU logical cores
* Rename tests subdirectories for Intel Core
* Update all tests
Since e4309a6c4bc3ad875711a1599cba01a205b3103e, new fields are reported by cpuid_tool
* Add Intel Alder Lake
Fix#157
* Remove convert_instlatx64.c
This tool is not useful anymore because the cpuid_deserialize_raw_data_internal() function can natively parse them since 5667e1401c
* Fix affinity_mask computation
* Define _GNU_SOURCE in configure.ac
Forgotten in 4f80964db5
* Use dynamic raw array in cpu_raw_data_array_t
* Add cpu_affinity_mask_t type
* Improve set_cpu_affinity function
- Print a warning if logical CPU number is not supported on operating system
- Return a boolean value in case of success instead of an integer
* Improve cpu_identify_all and cpu_request_core_type functions
* Use dynamic array for cpu_types in system_id_t
This commit also adds cleanups, fixes and consistency
* Tests: update Ryzen 5 Matisse with all CPU cores
* Add affinity_mask_str_r function and address other comments
- Fixed cpuid_grow_raw_data_array and cpu_raw_data_array_t.logical_cpu_t with the correct type
- Added a note about hard limit of cpu_raw_data_array_t
- Fixed a typo in cpuid_deserialize_raw_data_internal
* Fix build on Windows
Some CPUs does not have the same associativity for L1D and L1I, as reported in X0rg/CPU-X#119
It adds l1_instruction_assoc and l1_instruction_cacheline in cpu_id_t
To avoid confusing, also adds l1_data_assoc and l1_data_cacheline
l1_assoc and l1_cacheline are leave untouched for backward compatibility
Other, non-special options like `--cache' output strictly one line.
--sgx is not like that, because how much data it will print depends
on the machine it is being run.
Initial commit adding support for detection of SGX. Not tested yet.
Increment version number due to binary incompatibility of the
sizes of cpu_raw_data_t and cpu_id_t.
The new project files are for Microsoft Visual Studio 2010.
The configurations now support building both 32- and 64-bit targets,
and the "Release DLL" target is supported much like in the vc71 project.
The output layout is as follows:
32-bit, Debug static library goes to libcpuid/x32/Debug
32-bit, Release static library goes to libcpuid/x32/Release
32-bit, DLL (only release) goes to libcpuid/x32/ReleaseDLL. It includes
the .dll and the export library .lib as well.
64-bit DLL goes to libcpuid/x64/ReleaseDLL.
and so forth.
The .am files contained obsolete data (to include libcpuid.sln/libcpuid.vcproj
in a dist). These files are now in libcpuid_vc71.* and libcpuid_vc9.* flavours,
thus this change. "make dist" now works.
cpuid_tool: the --load flag didn't have any effect with queries; fixed
tests: added a trivial testing framework, added 7 tests
git-svn-id: https://svn.code.sf.net/p/libcpuid/code/HEAD/libcpuid@28 3b4be424-7ac5-41d7-8526-f4ddcb85d872
