Re: [PATCH] kbuild, x86: revert macros in extended asm workarounds
From: Nadav Amit
Date: Tue Dec 18 2018 - 14:33:15 EST
> On Dec 17, 2018, at 1:16 AM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
> On Thu, Dec 13, 2018 at 10:19 AM Masahiro Yamada
> <yamada.masahiro@xxxxxxxxxxxxx> 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:
>> 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
>> 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@xxxxxxxxxxxx> # distcc
>> Reported-by: Sedat Dilek <sedat.dilek@xxxxxxxxx> # debian/rpm package
> I reported the issue with debian package breakage in .
> 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.