Re: Problems compiling with KCFLAGS="-frecord-gcc-switches"

[Guenter Roeck]

On 09/29/2017 01:46 PM, Josh Poimboeuf wrote:
> On Fri, Sep 29, 2017 at 01:00:56PM -0700, Guenter Roeck wrote:
> > Hi Josh,
> >
> > when trying to compile an image with KCFLAGS="-frecord-gcc-switches",
> > I get the folllowing build warning/error.
> >
> > make allmodconfig
> > KCFLAGS="-frecord-gcc-switches" make arch/x86/kvm/emulate.o
> > ./tools/objtool/objtool check --no-unreachable "arch/x86/kvm/emulate.o"
> >
> > arch/x86/kvm/emulate.o: warning:
> > 	objtool: .GCC.command.line+0x0: special: can't find new instruction
> >
> > Building a full image aborts with:
> >
> > WARNING: arch/x86/kvm/kvm.o(__ex_table+0x4c): Section mismatch in reference
> > 	from the (unknown reference) (unknown)
> > 	to the variable .GCC.command.line:kvm_fastop_exception
> > FATAL: The relocation at __ex_table+0x4c references
> > section ".GCC.command.line" which is not executable, IOW
> > the kernel will fault if it ever tries to
> > jump to it.  Something is seriously wrong
> > and should be fixed.
> > make[2]: *** [arch/x86/kvm/kvm.o] Error 1
> >
> > Any idea what might cause this problem ?
>
> I think this is a GCC bug with the -frecord-gcc-switches feature.  Due
> to some ambiguity in some inline asm in emulate.c, it's placing some
> kernel code in the .GCC.command.line section.

Interesting. Makes me wonder if it is doing something similar in the efi code.

> This seems to fix it:
>
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index a36254cbf776..d90cdc77e077 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -425,8 +425,10 @@ static int fastop(struct x86_emulate_ctxt *ctxt, void (*fop)(struct fastop *));
>   	#op " %al \n\t" \
>   	FOP_RET
>   
> -asm(".global kvm_fastop_exception \n"
> -    "kvm_fastop_exception: xor %esi, %esi; ret");
> +asm(".pushsection .fixup, \"ax\"\n"
> +    ".global kvm_fastop_exception \n"
> +    "kvm_fastop_exception: xor %esi, %esi; ret\n"
> +    ".popsection");
>   
>   FOP_START(setcc)
>   FOP_SETCC(seto)

Yes, that fixes the problem for me.

Do you want to send a real patch ? If yes, feel free to add

Tested-by: Guenter Roeck <linux@xxxxxxxxxxxx>

Thanks,
Guenter