On Fri, 23 Aug 2024, Reinette Chatre wrote:
On 8/23/24 3:47 AM, Ilpo Järvinen wrote:
On Thu, 22 Aug 2024, Reinette Chatre wrote:
On 8/22/24 1:11 AM, Ilpo Järvinen wrote:
Building resctrl selftest fails on ARM because it uses __cpuid_count() that fails the build with error:
CC resctrl_testsIn file included from resctrl.h:24, from cat_test.c:11: In function 'arch_supports_noncont_cat', inlined from 'noncont_cat_run_test' at cat_test.c:323:6: ../kselftest.h:74:9: error: impossible constraint in 'asm' 74 | __asm__ __volatile__ ("cpuid\n\t" \ | ^~~~~~~ cat_test.c:301:17: note: in expansion of macro '__cpuid_count' 301 | __cpuid_count(0x10, 1, eax, ebx, ecx, edx); | ^~~~~~~~~~~~~ ../kselftest.h:74:9: error: impossible constraint in 'asm' 74 | __asm__ __volatile__ ("cpuid\n\t" \ | ^~~~~~~ cat_test.c:303:17: note: in expansion of macro '__cpuid_count' 303 | __cpuid_count(0x10, 2, eax, ebx, ecx, edx); | ^~~~~~~~~~~~~
The resctrl selftest would run that code only on Intel CPUs but as is, the code cannot be build at all.
Provide an empty stub for __cpuid_count() if it is not supported to allow build to succeed. The stub casts its arguments to void to avoid causing variable unused warnings.
Fixes: ae638551ab64 ("selftests/resctrl: Add non-contiguous CBMs CAT test") Reported-by: Muhammad Usama Anjum usama.anjum@collabora.com Signed-off-by: Ilpo Järvinen ilpo.jarvinen@linux.intel.com Tested-by: Muhammad Usama Anjum usama.anjum@collabora.com Reviewed-by: Muhammad Usama Anjum usama.anjum@collabora.com
v2:
- Removed RFC & added Fixes and Tested-by
- Fixed the error message's line splits
- Noted down the reason for void casts in the stub
tools/testing/selftests/kselftest.h | 6 ++++++ tools/testing/selftests/lib.mk | 4 ++++ 2 files changed, 10 insertions(+)
diff --git a/tools/testing/selftests/kselftest.h b/tools/testing/selftests/kselftest.h index b8967b6e29d5..71593add1b39 100644 --- a/tools/testing/selftests/kselftest.h +++ b/tools/testing/selftests/kselftest.h @@ -70,10 +70,16 @@ * have __cpuid_count(). */ #ifndef __cpuid_count +#ifdef HAVE_CPUID #define __cpuid_count(level, count, a, b, c, d) \ __asm__ __volatile__ ("cpuid\n\t" \ : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \ : "0" (level), "2" (count)) +#else +#define __cpuid_count(level, count, a, b, c, d) do { \
- (void)a; (void)b; (void)c; (void)d; \
The changelog states that this casting to void is done to avoid unused variable warnings. It is thus unexpected that not all parameters obtain the same casting treatment. It looks to me as though this only targets the resctrl selftest usage where the "level" and "count" parameters are constants.
The reason is entirely separate from what resctrl selftest expects. a-d are output parameters for __cpuid_count(), they need this treatment because they are typically not initialized but set by __cpuid_count() so if __cpuid_count() is doing literally nothing, nothing touches those four variables leading to unused variable warning.
This is intended as a general kselftest solution so I believe that all parameters would need this casting to handle the cases where "level" and/or "count" are variables.
No, the same issue does not exist for input parameters because it would be a valid warning. Passing uninitialized (and thus unused) input variable is wrong so the calling logic is wrong. Thus, I don't see how the same error could ever occur in a legitimate case for those two parameters.
If I understand correctly, the scenarios below are legitimate cases and will produce compile warnings with this patch applied. It is not obvious to me that the calling logic is wrong in these cases. If the output parameters get special treatment to avoid compile warnings, should input parameters not also?
scenario 1: unsigned int level = 0x10, count = 1; unsigned int a, b, c, d;
__cpuid_count(level, count, a, b, c ,d);
Above produces "unused variable" warnings for level and count.
scenario 2: unsigned int level, count, a, b, c, d;
level = 0x10; count = 1; __cpuid_count(level, count, a, b, c ,d);
Above produces "set but not used" warnings for level and count.
Ah, so you meant a different warning. Yes, I'll add void casts for those input parameters as well to avoid this.
The changelog states that the goal of this change is to produce an empty stub. To me this creates expectation of what we are used to and expect from if it would be an actual empty stub. For example, static inline void __cpuid_count(unsigned level, unsigned count, unsigned int a, unsigned b, unsigned int c, unsigned d) { }
For void functions, yes. But if it would return int, it wouldn't be literally "empty", that is, it is still be empty stub but does something so a very literal interpretation of "empty" is flawed anyway. But I can drop empty word from there, "stub" seems enough for the purpose.
If you on the other hand meant macros cannot be called "stub", what should they be called if not "stub"?
+} while (0) +#endif #endif /* define kselftest exit codes */ diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk index d6edcfcb5be8..236db9b24037 100644 --- a/tools/testing/selftests/lib.mk +++ b/tools/testing/selftests/lib.mk @@ -199,6 +199,10 @@ clean: $(if $(TEST_GEN_MODS_DIR),clean_mods_dir) # Build with _GNU_SOURCE by default CFLAGS += -D_GNU_SOURCE= +ifeq ($(ARCH),$(filter $(ARCH),x86 x86_64)) +CFLAGS += -DHAVE_CPUID= +endif
My earlier comment [1] when this work started remains. This technique depends on environment passing ARCH, which cannot be guaranteed. Looking at other usages of ARCH in the kselftest Makefiles it seems that the pattern is to initialize ARCH with "uname -m" if unset.
- # Enables to extend CFLAGS and LDFLAGS from command line, e.g. # make USERCFLAGS=-Werror USERLDFLAGS=-static CFLAGS += $(USERCFLAGS)
Reinette
[1] https://lore.kernel.org/lkml/db16db55-5f68-484f-ba9f-3312b41bf426@intel.com/
Ah, sorry. I'd missed that comment because it started mid-paragraph.
Where are comments required to start?
Obviously it's not a requirement, but I'd put each recommendation into own paragraph to maximize likelihoods its not missed. Despite the paragraph containing answers to two different questions, my mind I only registered the answer for the trivial program question. Again, I'm sorry about that.