Re: [PATCH] kbuild, x86: revert macros in extended asm workarounds

[Nadav Amit <namit@vmware.com>]

> On Dec 17, 2018, at 1:16 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> 
> On Thu, Dec 13, 2018 at 10:19 AM Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>> Revert the following commits:
>> 
>> - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd
>>  ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs")
>> 
>> - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2
>>  ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining bugs")
>> 
>> - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200.
>>  ("x86/extable: Macrofy inline assembly code to work around GCC inlining bugs")
>> 
>> - 494b5168f2de009eb80f198f668da374295098dd.
>>  ("x86/paravirt: Work around GCC inlining bugs when compiling paravirt ops")
>> 
>> - f81f8ad56fd1c7b99b2ed1c314527f7d9ac447c6.
>>  ("x86/bug: Macrofy the BUG table section handling, to work around GCC inlining bugs")
>> 
>> - 77f48ec28e4ccff94d2e5f4260a83ac27a7f3099.
>>  ("x86/alternatives: Macrofy lock prefixes to work around GCC inlining bugs")
>> 
>> - 9e1725b410594911cc5981b6c7b4cea4ec054ca8.
>>  ("x86/refcount: Work around GCC inlining bug")
>>  (Conflicts: arch/x86/include/asm/refcount.h)
>> 
>> - c06c4d8090513f2974dfdbed2ac98634357ac475.
>>  ("x86/objtool: Use asm macros to work around GCC inlining bugs")
>> 
>> - 77b0bf55bc675233d22cd5df97605d516d64525e.
>>  ("kbuild/Makefile: Prepare for using macros in inline assembly code to work around asm() related GCC inlining bugs")
>> 
>> A few days after those commits applied, discussion started to solve
>> the issue more elegantly on the compiler side:
>> 
>>  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F10%2F7%2F92&amp;data=02%7C01%7Cnamit%40vmware.com%7C40b5df8a38e54f310ab708d664005ee0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636806350113136223&amp;sdata=RlYXSyhzM6HLQuKC2NuyDqvke9qZ11tvMDNd32NiF2U%3D&amp;reserved=0
>> 
>> The "asm inline" was implemented by Segher Boessenkool, and now queued
>> up for GCC 9. (People were positive even for back-porting it to older
>> compilers).
>> 
>> Since the in-kernel workarounds merged, some issues have been reported:
>> breakage of building with distcc/icecc, breakage of distro packages for
>> module building. (More fundamentally, we cannot build external modules
>> after 'make clean')
>> 
>> Patching around the build system would make the code even uglier.
>> 
>> Given that this issue will be solved in a cleaner way sooner or later,
>> let's revert the in-kernel workarounds, and wait for GCC 9.
>> 
>> Reported-by: Logan Gunthorpe <logang@deltatee.com> # distcc
>> Reported-by: Sedat Dilek <sedat.dilek@gmail.com> # debian/rpm package
> 
> Hi,
> 
> I reported the issue with debian package breakage in [1].
> 
> I am not subscribed to any involved mailing-list and not following all
> the discussions.
> I see the situation is not easy as there is especially linux-kbuild
> and linux/x86 involved and maybe other interests.
> But I am interested in having a fix in v4.20 final and hope this all
> still works with LLVM/Clang.
> 
> I can offer my help in testing - against Linux v4.20-rc7.
> Not sure if all discussed material is in upstream or elsewhere.
> What is your suggestion for me as a tester?
> 
> Will we have a solution in Linux v4.20 final?

Thanks for the reference. I see solutions have already been developed. So
it’s Masahiro’s call.