On 10.02.2026 12:15, Andrew Cooper wrote:
> On 07/10/2025 4:58 pm, Jan Beulich wrote:
>> On 04.10.2025 00:53, Andrew Cooper wrote:
>>> FRED and IDT differ by a Supervisor Token on the base of the shstk.  This
>>> means that switch_stack_and_jump() needs to discard one extra word when FRED
>>> is active.
>>>
>>> Fix a typo in the parameter name, which should be shstk_base.
>>>
>>> Signed-off-by: Andrew Cooper <[email protected]>
>>> Reviewed-by: Jan Beulich <[email protected]>
>>> ---
>>> CC: Jan Beulich <[email protected]>
>>> CC: Roger Pau Monné <[email protected]>
>>>
>>> Leave as $%c.  Otherwise it doesn't assemble correctly presented with 
>>> $$24568
>>> to parse as an instruction immediate.
>> I don't follow. Where would the 2nd $ come from if you write ...
>>
>>> --- a/xen/arch/x86/include/asm/current.h
>>> +++ b/xen/arch/x86/include/asm/current.h
>>> @@ -154,7 +154,9 @@ unsigned long get_stack_dump_bottom (unsigned long sp);
>>>      "rdsspd %[ssp];"                                            \
>>>      "cmp $1, %[ssp];"                                           \
>>>      "je .L_shstk_done.%=;" /* CET not active?  Skip. */         \
>>> -    "mov $%c[skstk_base], %[val];"                              \
>>> +    ALTERNATIVE("mov $%c[shstk_base], %[val];",                 \
>>> +                "mov $%c[shstk_base] + 8, %[val];",             \
>>> +                X86_FEATURE_XEN_FRED)                           \
>>     ALTERNATIVE("mov %[shstk_base], %[val];",                   \
>>                 "mov %[shstk_base] + 8, %[val];",               \
>>                 X86_FEATURE_XEN_FRED)                           \
> 
> I find this feedback completely uncharacteristic.  You always goes out
> of your way to hide % inside macros to prohibit non-register operands.
> 
> This is exactly the same, except to force an immediate operand, so the
> length of the two instructions is the same.

Might there be some misunderstanding? $%c isn't what forces an immediate
operand. It's the constraint (not visible above) which does. What we see
above is only an elaborate form of a format string, requiring that
operands are already of appropriate type (arranged for by way of the
corresponding constraint). If a modifier character like 'c' doesn't apply
to the type of operand selected, the compiler may issue a diagnostic, may
ignore the modifier, or may emit code the assembler can't make sense of.
(Of course a particular modifier character could, in principle, also have
different meaning for different kinds of operands.)

Jan

Reply via email to