linux-kernel - Re: [PATCH v4 1/9] Makefile: Prepare for using macros for inline asm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 17 Jun 2018 09:40:56 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Nadav Amit <namit@...are.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        X86 ML <x86@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v4 1/9] Makefile: Prepare for using macros for inline asm

Hi.

2018-06-14 7:19 GMT+09:00 Nadav Amit <namit@...are.com>:
>>
>>
>> I have not fully understood this series yet.
>>
>> I do not have enough skill in x86 architecture,
>> but just some comments from the build system point of view.
>>
>>
>>
>> I guess this will probably break the parallel building.
>>
>> Kbuild can build 'prepare' and 'scripts' simultaneously.
>>
>>
>> I locally modified the following line:
>>
>>
>> diff --git a/Makefile b/Makefile
>> index 2dea909440..6ad484a 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1030,7 +1030,7 @@ $(sort $(vmlinux-deps)): $(vmlinux-dirs) ;
>> # Error messages still appears in the original language
>>
>> PHONY += $(vmlinux-dirs)
>> -$(vmlinux-dirs): prepare scripts
>> +$(vmlinux-dirs): scripts prepare
>>        $(Q)$(MAKE) $(build)=$@ need-builtin=1
>>
>> define filechk_kernel.release
>>
>>
>>
>> masahiro@...ver:~/workspace/linux-kbuild$ make  defconfig
>>  HOSTCC  scripts/basic/fixdep
>>  HOSTCC  scripts/kconfig/conf.o
>>  YACC    scripts/kconfig/zconf.tab.c
>>  LEX     scripts/kconfig/zconf.lex.c
>>  HOSTCC  scripts/kconfig/zconf.tab.o
>>  HOSTLD  scripts/kconfig/conf
>> *** Default configuration is based on 'x86_64_defconfig'
>> #
>> # configuration written to .config
>> #
>> masahiro@...ver:~/workspace/linux-kbuild$ make all
>> scripts/kconfig/conf  --syncconfig Kconfig
>>  WRAP    arch/x86/include/generated/uapi/asm/bpf_perf_event.h
>>  WRAP    arch/x86/include/generated/uapi/asm/poll.h
>>  WRAP    arch/x86/include/generated/asm/dma-contiguous.h
>>  WRAP    arch/x86/include/generated/asm/early_ioremap.h
>>  WRAP    arch/x86/include/generated/asm/mcs_spinlock.h
>>  WRAP    arch/x86/include/generated/asm/mm-arch-hooks.h
>>  CC      scripts/mod/empty.o
>> Assembler messages:
>> Error: can't open arch/x86/kernel/macros.s for reading: No such file
>> or directory
>> make[2]: *** [scripts/Makefile.build:318: scripts/mod/empty.o] Error 1
>> make[1]: *** [scripts/Makefile.build:558: scripts/mod] Error 2
>> make: *** [Makefile:1050: scripts] Error 2
>
> You are right. I tried to filter out the use of the switch (exported as
> ASM_MACRO_FLAGS) for empty.o. Any suggestions on how to do it properly?


You can do like this:


diff --git a/scripts/mod/Makefile b/scripts/mod/Makefile
index 42c5d50..a5b4af4 100644
--- a/scripts/mod/Makefile
+++ b/scripts/mod/Makefile
@@ -4,6 +4,8 @@ OBJECT_FILES_NON_STANDARD := y
 hostprogs-y    := modpost mk_elfconfig
 always         := $(hostprogs-y) empty.o

+CFLAGS_REMOVE_empty.o := $(ASM_MACRO_FLAGS)
+
 modpost-objs   := modpost.o file2alias.o sumversion.o

 devicetable-offsets-file := devicetable-offsets.h





modpost is an exceptional hostprogam - it depends on
target compiler, which makes the build order complicated.

I want to compile under scripts/ only with $(HOSTCC).

I am planning to change modpost
target-independent by detecting
32/64 bit, little/big-endianness run-time.
Then, empty.c will go away.


In the meanwhile, CFLAGS_REMOVE_ will do
as a workaround.


-- 
Best Regards
Masahiro Yamada