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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel