On Wed, Nov 12, 2025 at 10:25 PM H. Peter Anvin <[email protected]> wrote: > > On 2025-11-12 02:31, Uros Bizjak wrote: > > > > Unfortunately, %ebp is still special with -fno-omit-frame-pointer, so > > using "ebp" as _sys_arg6 on 32-bit targets will result in: > > > > error: bp cannot be used in ‘asm’ here > > > > Please see how %ebp register is handled in > > arch/x86/include/asm/vmware.h, vmware_hypercall_hb_out() and > > vmware_hypercall_hb_in(). > > > > #ifdef CONFIG_X86_64 > #define VMW_BP_CONSTRAINT "r" > #else > #define VMW_BP_CONSTRAINT "m" > #endif > > asm_inline volatile ( > UNWIND_HINT_SAVE > "push %%" _ASM_BP "\n\t" > UNWIND_HINT_UNDEFINED > "mov %[in6], %%" _ASM_BP "\n\t" > "rep outsb\n\t" > "pop %%" _ASM_BP "\n\t" > UNWIND_HINT_RESTORE > : "=a" (out0), "=b" (*out1) > : "a" (VMWARE_HYPERVISOR_MAGIC), > "b" (cmd), > "c" (in2), > "d" (in3 | VMWARE_HYPERVISOR_PORT_HB), > "S" (in4), > "D" (in5), > [in6] VMW_BP_CONSTRAINT (in6) > : "cc", "memory"); > return out0; > > That code is actually incorrect, in at least two ways: > > > 1. It should be conditioned on frame pointers enabled, not x86-64 vs i386. > 2. The compiler is perfectly within its right to emit an %esp-relative > reference for the "m"-constrained [in6]. This is particularly likely > when *not* compiled with frame pointers, see #1. > > A better sequence might be: > > pushl %[in6] > push %ebp > mov 4(%esp),%ebp > <stuff> > pop %ebp > pop %[junk] > > Then %[in6] can even safely be a "g" constraint (hence pushl).
If we want to also handle x86_64, the above code (including push) needs to be 64-bit, with "rme" constraint for the pushed value. I have CC'd the author of the above code, he might be interested in the above discussion. Uros.
