[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181216100042.GA815@zn.tnic>
Date: Sun, 16 Dec 2018 11:00:42 +0100
From: Borislav Petkov <bp@...en8.de>
To: Nadav Amit <namit@...are.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H . Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
Richard Biener <rguenther@...e.de>,
Logan Gunthorpe <logang@...tatee.com>,
Sedat Dilek <sedat.dilek@...il.com>,
Segher Boessenkool <segher@...nel.crashing.org>,
linux-arch <linux-arch@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
Michal Marek <michal.lkml@...kovi.net>,
"linux-sparse@...r.kernel.org" <linux-sparse@...r.kernel.org>,
Alok Kataria <akataria@...are.com>,
Juergen Gross <jgross@...e.com>,
Andy Lutomirski <luto@...nel.org>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH] kbuild, x86: revert macros in extended asm workarounds
On Sun, Dec 16, 2018 at 02:33:39AM +0000, Nadav Amit wrote:
> In general, I think that from the start it was clear that the motivation for
> the patch-set is not just performance and also better code. For example, I
> see no reason to revert the PV-changes or the lock-prefix changes that
> improved the code readability.
One thing that has caught my eye with the asm macros, which actually
decreases readability, is that I can't see the macro properly expanded
when I do
make <filename>.s
For example, I get
#APP
# 164 "./arch/x86/include/asm/cpufeature.h" 1
STATIC_CPU_HAS bitnum=$8 cap_byte="boot_cpu_data+35(%rip)" feature=123 t_yes=.L75 t_no=.L78 always=117 #, MEM[(const char *)&boot_cpu_data + 35B],,,,
# 0 "" 2
.loc 11 164 2 view .LVU480
#NO_APP
but I'd like to see the actual asm as it is really helpful when hacking
on inline asm stuff. And I haven't found a way to make gcc expand asm
macros in .s output.
Now, assuming the gcc inline patch will be backported to gcc8, I think
we should be covered on all modern distros going forward. So I think we
should revert at least the more complex macros.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists