linux-kernel - Re: linux-next: build failure after merge of the tip tree

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]

Message-ID: <4A5E6F25-37B6-4114-AB3C-476F6F551DBD@zytor.com>
Date:   Thu, 13 May 2021 04:11:49 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Ingo Molnar <mingo@...nel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>
CC:     Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the tip tree

Needed some head scratching, but then...

It makes sense for the cross-build: it's building for the host, and a non-x86 machine isn't doing to have a register named "%rsp".

So this needs to be protected from non-kernel use either via __KERNEL__ or by factoring the basic macros out into a separate file.

Incidentally, we seem to have three categories of include files now: kernel-only, uapi, and "tools api". Perhaps we need such a "tapi" directory instead of copying things around... the infrastructure for uapi with make headers_install etc ought to be generalizable.


On May 13, 2021 3:51:47 AM PDT, Ingo Molnar <mingo@...nel.org> wrote:
>
>* Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
>> Hi all,
>> 
>> After merging the tip tree, today's linux-next build (x86_64
>allmodconfig)
>> failed like this:
>> 
>> In file included from tools/arch/x86/include/asm/nops.h:5,
>>                  from arch/x86/decode.c:15:
>> tools/arch/x86/include/asm/asm.h:185:24: error: invalid register name
>for 'current_stack_pointer'
>>   185 | register unsigned long current_stack_pointer asm(_ASM_SP);
>>       |                        ^~~~~~~~~~~~~~~~~~~~~
>> 
>> Caused by commit
>> 
>>   eef23e72b78b ("x86/asm: Use _ASM_BYTES() in <asm/nops.h>")
>> 
>> I have used the tip tree from next-20210512 for today.
>
>Hm, this must be some cross-build artifact or toolchain version
>dependency 
>- as plain native build of x86-64 allmodconfig builds just fine:
>
>    CC       arch/x86/decode.o
>    LD       arch/x86/objtool-in.o
>
>I tried with gcc-8, but that didn't trigger it.
>
>I suppose the workaround below would make it build - but that's not a
>real 
>solution.
>
>hpa, any ideas?
>
>Thanks,
>
>	Ingo
>
>diff --git a/tools/arch/x86/include/asm/asm.h
>b/tools/arch/x86/include/asm/asm.h
>index 507a37a46027..ada5482c024a 100644
>--- a/tools/arch/x86/include/asm/asm.h
>+++ b/tools/arch/x86/include/asm/asm.h
>@@ -176,14 +176,6 @@
> 
> /* For C file, we already have NOKPROBE_SYMBOL macro */
> 
>-/*
>- * This output constraint should be used for any inline asm which has
>a "call"
>- * instruction.  Otherwise the asm may be inserted before the frame
>pointer
>- * gets set up by the containing function.  If you forget to do this,
>objtool
>- * may print a "call without frame pointer save/setup" warning.
>- */
>-register unsigned long current_stack_pointer asm(_ASM_SP);
>-#define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)
> #endif /* __ASSEMBLY__ */
> 
> #endif /* _ASM_X86_ASM_H */

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.