[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzJ=5D64V_qOqecerteESmim4tVRn2PDacR6DYsTN3EdQ@mail.gmail.com>
Date: Wed, 25 May 2016 10:14:24 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>,
Ingo Molnar <mingo@...nel.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
DRI <dri-devel@...ts.freedesktop.org>
Subject: objtool warning: "duplicate frame pointer save"
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)
Linus
Powered by blists - more mailing lists