BPF vs objtool again

[Josh Poimboeuf]

On Thu, Jul 18, 2019 at 12:14:08PM -0700, tip-bot for Josh Poimboeuf wrote:
> Commit-ID:  3193c0836f203a91bef96d88c64cccf0be090d9c
> Gitweb:     https://git.kernel.org/tip/3193c0836f203a91bef96d88c64cccf0be090d9c
> Author:     Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> AuthorDate: Wed, 17 Jul 2019 20:36:45 -0500
> Committer:  Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> CommitDate: Thu, 18 Jul 2019 21:01:06 +0200
> 
> bpf: Disable GCC -fgcse optimization for ___bpf_prog_run()

For some reason, this

  __attribute__((optimize("-fno-gcse")))

is disabling frame pointers in ___bpf_prog_run().  If you compile with
CONFIG_FRAME_POINTER it'll show something like:

  kernel/bpf/core.o: warning: objtool: ___bpf_prog_run.cold()+0x7: call without frame pointer save/setup

Also, since GCC 9.1, the GCC docs say "The optimize attribute should be
used for debugging purposes only. It is not suitable in production
code."  That doesn't sound too promising.

So it seems like this commit should be reverted. But then we're back to
objtool being broken again in the RETPOLINE=n case, which means no ORC
coverage in this function.  (See above commit for the details)

Some ideas:

- Skip objtool checking of that func/file (at least for RETPOLINE=n) --
  but then it won't have ORC coverage.

- Get rid of the "double goto" in ___bpf_prog_run(), which simplifies it
  enough for objtool to understand -- but then the text explodes for
  RETPOLINE=y.

- Add -fno-gfcse to the Makefile for kernel/bpf/core.c -- but then that
  affects the optimization of other functions in the file.  However I
  don't think the impact is significant.

- Move ___bpf_prog_run() to its own file with the -fno-gfcse flag.  I'm
  thinking this could be the least bad option.  Alexei?

-- 
Josh