From: "tip-bot2 for Uros Bizjak" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Uros Bizjak <ubizjak@gmail.com>, Ingo Molnar <mingo@kernel.org>,
Andy Lutomirski <luto@kernel.org>,
Brian Gerst <brgerst@gmail.com>, Juergen Gross <jgross@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Rik van Riel <riel@surriel.com>, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: x86/mm] x86/idle: Remove .s output beautifying delimiters from simpler asm() templates
Date: Wed, 02 Apr 2025 20:43:51 -0000 [thread overview]
Message-ID: <174362663153.14745.130124754457441192.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20250402180827.3762-3-ubizjak@gmail.com>
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 8ad521aaf7438e4fae996f51d02b960cc97a15a3
Gitweb: https://git.kernel.org/tip/8ad521aaf7438e4fae996f51d02b960cc97a15a3
Author: Uros Bizjak <ubizjak@gmail.com>
AuthorDate: Wed, 02 Apr 2025 20:08:07 +02:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Wed, 02 Apr 2025 22:36:57 +02:00
x86/idle: Remove .s output beautifying delimiters from simpler asm() templates
Delimiters in asm() templates such as ';', '\t' or '\n' are not
required syntactically, they were used historically in the Linux
kernel to prettify the compiler's .s output for people who were
looking at compiler generated .s output.
Most x86 developers these days are primarily looking at:
1) objdump --disassemble-all .o
2) perf top's live kernel function annotation and disassembler
feature that uses /dev/mem.
... because:
- this kind of assembler output is standardized regardless of
compiler used,
- it's generally less messy looking,
- it gives ground-truth instead of being some intermediate layer
in the toolchain that might or might not be the real deal,
- and on a live kernel it also sees through the kernel's various
layers of runtime patching code obfuscation facilities, also
known as: alternative-instructions, tracepoints and jump labels.
There are some cases where the .s output is the most useful
tool, such as alternatives() code generation, but other than
that these delimiters used in simple asm() statements mostly
add noise to the source code side, which isn't desirable for
assembly code that is fragile enough already.
Remove the delimiters for <asm/mwait.h>, which also happens to
make the GCC inliner's asm() instruction length heuristics
more accurate...
[ mingo: Wrote a new changelog to give historic context and
to give people a chance to object. :-) ]
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250402180827.3762-3-ubizjak@gmail.com
---
arch/x86/include/asm/mwait.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/mwait.h b/arch/x86/include/asm/mwait.h
index 006b150..6522886 100644
--- a/arch/x86/include/asm/mwait.h
+++ b/arch/x86/include/asm/mwait.h
@@ -32,8 +32,8 @@ static __always_inline void __monitor(const void *eax, u32 ecx, u32 edx)
static __always_inline void __monitorx(const void *eax, u32 ecx, u32 edx)
{
- /* "monitorx %eax, %ecx, %edx;" */
- asm volatile(".byte 0x0f, 0x01, 0xfa;"
+ /* "monitorx %eax, %ecx, %edx" */
+ asm volatile(".byte 0x0f, 0x01, 0xfa"
:: "a" (eax), "c" (ecx), "d"(edx));
}
@@ -74,8 +74,8 @@ static __always_inline void __mwaitx(u32 eax, u32 ebx, u32 ecx)
{
/* No MDS buffer clear as this is AMD/HYGON only */
- /* "mwaitx %eax, %ebx, %ecx;" */
- asm volatile(".byte 0x0f, 0x01, 0xfb;"
+ /* "mwaitx %eax, %ebx, %ecx" */
+ asm volatile(".byte 0x0f, 0x01, 0xfb"
:: "a" (eax), "b" (ebx), "c" (ecx));
}
@@ -133,13 +133,13 @@ static __always_inline void mwait_idle_with_hints(unsigned long eax, unsigned lo
*/
static inline void __tpause(u32 ecx, u32 edx, u32 eax)
{
- /* "tpause %ecx, %edx, %eax;" */
+ /* "tpause %ecx, %edx, %eax" */
#ifdef CONFIG_AS_TPAUSE
- asm volatile("tpause %%ecx\n"
+ asm volatile("tpause %%ecx"
:
: "c"(ecx), "d"(edx), "a"(eax));
#else
- asm volatile(".byte 0x66, 0x0f, 0xae, 0xf1\t\n"
+ asm volatile(".byte 0x66, 0x0f, 0xae, 0xf1"
:
: "c"(ecx), "d"(edx), "a"(eax));
#endif
next prev parent reply other threads:[~2025-04-02 20:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 18:08 [PATCH -tip 1/4] x86/idle: Fix argument type for MONITOR{,X} and MWAIT{,X} instructions Uros Bizjak
2025-04-02 18:08 ` [PATCH -tip 2/4] x86/idle: Use MONITOR and MWAIT mnemonics in <asm/mwait.h> Uros Bizjak
2025-04-02 20:43 ` [tip: x86/mm] " tip-bot2 for Uros Bizjak
2025-04-03 15:28 ` [PATCH -tip 2/4] " Andy Shevchenko
2025-04-03 15:30 ` Andy Shevchenko
2025-04-03 15:33 ` Ingo Molnar
2025-04-03 15:41 ` Andy Shevchenko
2025-04-02 18:08 ` [PATCH -tip 3/4] x86/idle: Remove unneeded delimiters from asm templates Uros Bizjak
2025-04-02 20:43 ` tip-bot2 for Uros Bizjak [this message]
2025-04-03 11:27 ` [tip: x86/mm] x86/idle: Remove .s output beautifying delimiters from simpler asm() templates tip-bot2 for Uros Bizjak
2025-04-02 18:08 ` [PATCH -tip 4/4] x86/idle: Remove CONFIG_AS_TPAUSE Uros Bizjak
2025-04-02 20:43 ` [tip: x86/mm] " tip-bot2 for Uros Bizjak
2025-04-02 20:55 ` tip-bot2 for Uros Bizjak
2025-04-03 11:27 ` tip-bot2 for Uros Bizjak
2025-04-02 20:43 ` [tip: x86/mm] x86/idle: Standardize argument types for MONITOR{,X} and MWAIT{,X} instruction wrappers on 'u32' tip-bot2 for Uros Bizjak
2025-04-02 23:26 ` Andrew Cooper
2025-04-02 20:48 ` [PATCH -tip 1/4] x86/idle: Fix argument type for MONITOR{,X} and MWAIT{,X} instructions Ingo Molnar
2025-04-02 21:18 ` Uros Bizjak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=174362663153.14745.130124754457441192.tip-bot2@tip-bot2 \
--to=tip-bot2@linutronix.de \
--cc=andrew.cooper3@citrix.com \
--cc=brgerst@gmail.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=riel@surriel.com \
--cc=torvalds@linux-foundation.org \
--cc=ubizjak@gmail.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®