[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 1/2] x86emul: mark the trimmed emulator's section-internal labels maybe-unused
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: "Chen, Shuaidong" <Shuaidong.Chen@xxxxxxx>
- Date: Tue, 10 Nov 2026 21:05:49 +0800
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=plY/X3S4IxeE2+9jEmCtopgc9f1ulD1AfmuCW9INAtY=; b=nSmZBC0BrwNx7fL4Abvt0YsLNUTq8m+/HhB/jJ0BVB4N4L9kk8grg7UZpxHkkem3MlObcmbb3t00BXv5hG9QGKjL8ySwsrM8NRJUml/l1YGhPYvXn+NkiZT/kzqyZxkIPwZXRtYXRlJDwUw1paV129k8mqVp1AKlyhjm1yEj7GeiNi2dYl2QnVqnyQvlt4kqkdqU1txKTDak4Guq0HpP4CPqmR+E6GIGCvAh8pUgQorCep8uIrtWBa2+JGpaUswEhohtjpFroqn+1KIlVpJQCUsqIjzXkzz2y94h3QWzBSgDpTuHk5z118PZfJV1BmRP3KfEYYDEMTDV8CIQMexyAA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gMcULA4aLqtmBxkXO3pyd0vqZVb0D7HKaVane9H48KTYS173wU/QQMcN+SsX7EDn3fkneeC936LhI+tF7PmyEHa/RLY9HSADJSD7jUJf9h7VnZ+rFTkqAX949yo0mgR3+gRfB3jOR5uily7XKxHnOpo31IwFwzirNPqtQLz50W94f5oyR7LE2yOmwQN01vHGprhb8G8pKKBwWjPSRlDUNYOW3Cu8h+InuZ99IZRPwC7vXxAE/YALBL5x4EYzNXGeA2QPE+LGbYTzvIFKcT/BO/EZLNW8REB2OEaec6xPagstnh9mBboy1dJLCimnpT/4E+OT2jjdQwC/5nZ+Njb0Lw==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Teddy Astie <teddy.astie@xxxxxxxxxx>, Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>, Grygorii Strashko <grygorii_strashko@xxxxxxxx>, Penny Zheng <penny.zheng@xxxxxxx>, Ray Huang <Ray.Huang@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Tue, 10 Nov 2026 13:06:13 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 11/10/2026 5:30 PM, Jan Beulich wrote:
On 10.11.2026 08:12, Shuaidong Chen wrote:
In builds where the FPU, MMX and SIMD sections of the emulator are
compiled out - with CONFIG_HVM=n, private.h defines X86EMUL_NO_FPU,
X86EMUL_NO_MMX and X86EMUL_NO_SIMD - every `goto' targeting
simd_0f_fp, simd_0f_xmm, simd_0f_ymm, simd_0f_cvt, simd_0f_mmx,
simd_0f_imm8_avx2, simd_0f_imm8_ymm, simd_0f38_common and
simd_0f3a_common is preprocessed out, while the labels themselves
stay. They are unused by construction, which the build already
acknowledges by passing -Wno-unused-label for this translation unit.
If we choose to go this route, why would we then keep passing that extra
compiler option?
We'd have to keep it: patch 1 only covers the 9 hand-written labels,
while the 82 labels coming from the CASE_SIMD_* macros stay unused in
this configuration, and the compiler would still warn about them.
As to going this route - I wonder what the other x86
maintainers think. Afaic: I can live with the annotations, but I wouldn't
be over happy see them appear (as their amount is only going to grow).
Fair enough. I'll drop the annotations, see below.
Say it on the labels as well, the way the rest of the tree does
(unimplemented_insn here, done in blk.c). That also clears the reports
MISRA C:2012 Rule 2.6 (advisory) - "A function should not contain unused
label declarations" - raises against them, with no new deviation:
docs/misra/deviations.rst already recognises __maybe_unused as the way
to express this.
Emulator code is excluded from scanning in various other regards. Is there
a particular reason why this rule needs complying with?
Jan
No strong one. R2.6 is advisory, and the reports only show up in an
HVM-less configuration that upstream's ECLAIR jobs don't analyse.
--
Thx and BRs,
Shuaidong Chen
|
