All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Problems compiling with KCFLAGS="-frecord-gcc-switches"
Date: Fri, 29 Sep 2017 13:38:43 -0700	[thread overview]
Message-ID: <20170929203843.GA6611@roeck-us.net> (raw)
In-Reply-To: <20170929200056.GA3303@roeck-us.net>

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 ?
> 

Here is another interesting problem, seen when building arm64 allmodconfig
-CONFIG_CPU_BIG_ENDIAN +CONFIG_EFI.

kallsyms failure:
	relative symbol value 0xffffff9008073000 out of range in relative mode

This is due to symbols such as

000000000000000e n __efistub_$d

in the symbol table. Those are not filtered out by kallsyms, resulting in a
relative "base" address of 0x0e, and all other symbols are out of range.
Those symbols are only generated in efi/libstubs.

Any idea what might be going on there, and how to fix it ?
An easy fix would be something like

-       else if (stype == 'N')
+       else if (toupper(stype) == 'N')

in kallsyms, but that doesn't seem like a clean solution to me.

Thanks,
Guenter

  reply	other threads:[~2017-09-29 20:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-29 20:00 Problems compiling with KCFLAGS="-frecord-gcc-switches" Guenter Roeck
2017-09-29 20:38 ` Guenter Roeck [this message]
2017-09-29 20:58   ` Josh Poimboeuf
2017-09-29 23:08     ` Guenter Roeck
2017-09-29 20:46 ` Josh Poimboeuf
2017-09-30  1:07   ` Guenter Roeck
2017-10-03 17:54   ` Guenter Roeck
2017-10-03 18:00     ` Josh Poimboeuf
2017-10-03 20:27       ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170929203843.GA6611@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.