[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <307823F9-DCCF-4384-9FBE-28642FAD6B4E@vmware.com>
Date: Wed, 26 Sep 2018 17:56:06 +0000
From: Nadav Amit <namit@...are.com>
To: Rasmus Villemoes <linux@...musvillemoes.dk>,
Ingo Molnar <mingo@...hat.com>
CC: LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Sam Ravnborg <sam@...nborg.org>,
Michal Marek <michal.lkml@...kovi.net>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
"linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v8 02/10] Makefile: Prepare for using macros for inline
asm
at 1:58 AM, Rasmus Villemoes <linux@...musvillemoes.dk> wrote:
> On 2018-09-18 23:28, Nadav Amit wrote:
>
>> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>> index 8f6e7eb8ae9f..944fa3bc9376 100644
>> --- a/arch/x86/Makefile
>> +++ b/arch/x86/Makefile
>> @@ -214,8 +214,8 @@ ifdef CONFIG_X86_64
>> KBUILD_LDFLAGS += $(call ld-option, -z max-page-size=0x200000)
>> endif
>>
>> -# Speed up the build
>> -KBUILD_CFLAGS += -pipe
>> +# We cannot use -pipe flag since we give an additional .s file to the compiler
>> +#KBUILD_CFLAGS += -pipe
>
> Is this really necessary? The gas manual says that one can use -- to
> name stdin, though that's probably a typo and should just be - . Doing
>
> gcc -pipe -Wa,foo.s -Wa,-
Good idea. I didn’t think of it. Yes, this can do the trick. I’ll do it in
v9.
> does seem to work as expected (and would also make it possible to append
> some .s file should that ever be required).
>> +archmacros:
>> + $(Q)$(MAKE) $(build)=arch/x86/kernel arch/x86/kernel/macros.s
>> +
>> +ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s
>> +export ASM_MACRO_FLAGS
>> +KBUILD_CFLAGS += $(ASM_MACRO_FLAGS)
> How does this affect what gets rebuilt when one of the asm/foo.h files
> going into macros.s changes? Does that cause a global rebuild because
> everything depends on macros.s, or do we still only rebuild the files
> that actually include asm/foo.h?
There will not be a global rebuild. Any source file that uses the header
files that are included in macros.S will be rebuilt.
But your question actually raises two issues:
1. If macros.S changes, there *should* be a global rebuild, and currently
there wouldn’t be one. Do you happen to know what would be the appropriate
way to trigger one?
2. Someone might mistakenly use the macros through inline assembly without
including the header file. It would be better to detect such cases and fail
the build. I may be able to create another asm macro in the C part of the
header that would cause the build to fail. But let me know if you any
better idea.
Regards,
Nadav
Powered by blists - more mailing lists