Re: objtool warning: "duplicate frame pointer save"

[Josh Poimboeuf]

On Wed, May 25, 2016 at 10:14:24AM -0700, Linus Torvalds wrote:
> Josh,
>  my current git version (with gcc 5.3.1) makes objtool warn about
> "duplicate frame pointer save" in drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> for both vmw_send_msg() and vmw_host_get_guestinfo().
> 
> The reason is that VMW_PORT_HB_OUT() uses a magic instruction sequence
> (a "rep outsb") to communicate with the hypervisor (it's a virtual GPU
> driver for vmware), and %rbp is part of the communication. So the
> inline asm does a save-and-restore of the frame pointer around the
> instruction sequence.
> 
> I actually find the objtool warning to be quite reasonable, so it's
> not exactly a false positive, since in this case it actually does
> point out that the frame pointer won't be reliable over that
> instruction sequence.
> 
> But in this particular case it just ends up being the wrong thing -
> the code is what it is, and %rbp just can't have the frame information
> due to annoying magic calling conventions.
> 
> Is there some way to override objtool for this situation? I hate
> seeing warnings that I need to ignore, it has just too often caused me
> to mistakenly ignore warnings I *should* have reacted to.
> 
> I guess a STACK_FRAME_NON_STANDARD will shut objtool up (or just
> disabling it entirely for the whole file), but I was wondering about
> something more targeted that could be marked in the inline asm itself
> (rather than have to mark the functions that use it)

I used to have a STACKTOOL_IGNORE_INSN macro that would tell the tool to
skip warnings for specific instructions in inline asm:

Here's an example of it how it was used:

  https://lkml.kernel.org/r/c0c1a92df921961cae5cce208247bb8d8a975d6d.1450442274.git.jpoimboe@xxxxxxxxxx

And here's the implementation of the macro:

  https://lkml.kernel.org/r/cd7778181d2a5251c3dc21811fdbcaa2c16c98c3.1450442274.git.jpoimboe@xxxxxxxxxx

As it turns out, we didn't need the macro, so I removed it.  But I can
easily add something like that again to get rid of the warnings.

There were objections to having "OBJTOOL" in the names of macros, so I
guess I'll call it STACK_INSN_NON_STANDARD, unless anybody has a better
idea.

-- 
Josh