[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxewX-gBuo_=e2cfZ24WiE8X2oHqAdhVJD0LrSQ_AEqyA@mail.gmail.com>
Date: Fri, 23 Sep 2016 13:33:45 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Ingo Molnar <mingo@...nel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: new objtool warnings again...
Josh,
the current F24 toolchain causes
kernel/signal.o: warning: objtool: .altinstr_replacement+0x54:
call without frame pointer save/setup
during a regular allmodconfig build.
Doing an objdump says:
...
54: e8 00 00 00 00 callq 59 <.altinstr_replacement+0x59>
55: R_X86_64_PC32 copy_user_generic_string-0x4
59: e8 00 00 00 00 callq 5e <.altinstr_replacement+0x5e>
5a: R_X86_64_PC32
copy_user_enhanced_fast_string-0x4
...
so it seems to come from the alternative_call_2() in copy_user_generic().
It's somewhere in copy_siginfo_to_user(), so I assume it's just the
if (from->si_code < 0)
return __copy_to_user(to, from, sizeof(siginfo_t))
? -EFAULT : 0;
case. Looking at the code generation, it looks like the frame pointer
generation in that function has been moved down past this code, so the
objtool warning seems to be correct, but this indicates that gcc has
decided that we don't need a frame for that alternative_call_2()
thing.
So this code is clearly missing the magic to tell gcc that the asm
needs a frame pointer.
What was that magic again? Mind sending a patch?
Linus
Powered by blists - more mailing lists