On November 12, 2025 11:15:08 PM PST, Uros Bizjak <[email protected]> wrote: >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. >
For 64 bits, if you need frame pointer support *and* frob %rsp, using: xchg %[arg],%%rbp <stuff> xchg %[arg],%%rbp ... is probably easiest, with %[arg] in a register.
