-
Notifications
You must be signed in to change notification settings - Fork 11k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
\@ in two inline assembly expressions are parsed in isolation; so may lead to the same value, different from GCC #60792
Comments
Clang's behavior is different from GCC's but I am unsure it is considered as incorrect. For the concatenated module-level inline asm and each To achieve your goal, use extended asm (not usable outside a function) with https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#AssemblerTemplate
E.g. #define M ".L%=: add $%=, %%eax\n\t" :::
void a(void)
{
asm(M);
asm(M);
asm(M);
} |
I'm aware of In our case, it really is a macro coming in at the assembler level, and not a literal interpreted by the asm statement. https://github.com/xen-project/xen/blob/master/xen/arch/x86/include/asm/spec_ctrl_asm.h#L120-L161 I know that I'm going to have to find some solution to this urgently, but in all seriousness, by resetting the expansion count, you're breaking the major thing that |
The best way to do this sort of thing is to never use named labels in a macro, but instead use numbered labels, which you refer to with the "b" (backward) or "f" (forward) suffixes. There can be any number of such labels -- references always find the closest one in the given direction. See https://sourceware.org/binutils/docs/as/Symbol-Names.html That is, you'd have: asm ("toplevel:\n\t" |
No - that prohibited by our coding style for a very good reason. Numeric labels have no scoping, so if you have nested macros that use the same numbers, the eventual expansion ends up wrong. It creates very subtle bugs. Some projects (including Linux) work around it by having people pick random numbers for labels and hoping they don't collide. We work around it by using |
Ok. Can I pose a different question then. Would you consider it an error for |
I think this came up in the past with a discussion with @jcai19 (I'd have to dig through previous bug reports). I kind of wonder if the current design is intentional or not. |
llvm/llvm-project#60792 RFC. I very much dislike this patch, but it does work for me. Why the parameter name of foo? Turns out I found a different Clang-IAS bug/misfeature when trying to name the parameter uniq. In file included from arch/x86/asm-macros.c:3: ./arch/x86/include/asm/spec_ctrl_asm.h:139:5: error: \u used with no following hex digits; treating as '\' followed by identifier [-Werror,-Wunicode] .L\@\uniq\()fill_rsb_loop: ^ It appears you can't have any macro parameters beginning with a u. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> CC: Roger Pau Monné <roger.pau@citrix.com> CC: Wei Liu <wl@xen.org>
Seems the Github robots are ahead of me, but yes - I've found a workaround by muxing But I've found a different parsing bug too, which ultimately prevents the use of any macro parameter whose name begins with a |
llvm/llvm-project#60792 It turns out that Clang-IAS does not expand \@ uniquely in a translaition unit, and the XSA-426 change tickles this bug: <instantiation>:4:1: error: invalid symbol redefinition .L1_fill_rsb_loop: ^ make[3]: *** [Rules.mk:247: arch/x86/acpi/cpu_idle.o] Error 1 Extend DO_OVERWRITE_RSB with an optional parameter so C callers can mux %= in too, which Clang does seem to expand properly. Fixes: 63305e5 ("x86/spec-ctrl: Mitigate Cross-Thread Return Address Predictions") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> CC: Roger Pau Monné <roger.pau@citrix.com> CC: Wei Liu <wl@xen.org> v1 (vs RFC): * Rename \foo to \x, reorder WRT \@ to avoid needing \() too. I originally tried a parameter named uniq but this found a different Clang-IAS bug: In file included from arch/x86/asm-macros.c:3: ./arch/x86/include/asm/spec_ctrl_asm.h:139:5: error: \u used with no following hex digits; treating as '\' followed by identifier [-Werror,-Wunicode] .L\@\uniq\()fill_rsb_loop: ^ It appears that Clang is looking for unicode escapes before completing parameter substitution. But the macro didn't originate from a context where a unicode escape was even applicable to begin with. The consequence is that you can't use macro prameters beginning with a u.
The design of resetting most state is intentional. That this counter is not explicitly preserved is an oversight, I think, and could/should indeed be fixed. |
llvm/llvm-project#60792 It turns out that Clang-IAS does not expand \@ uniquely in a translaition unit, and the XSA-426 change tickles this bug: <instantiation>:4:1: error: invalid symbol redefinition .L1_fill_rsb_loop: ^ make[3]: *** [Rules.mk:247: arch/x86/acpi/cpu_idle.o] Error 1 Extend DO_OVERWRITE_RSB with an optional parameter so C callers can mix %= in too, which Clang does seem to expand properly. Fixes: 63305e5 ("x86/spec-ctrl: Mitigate Cross-Thread Return Address Predictions") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
llvm/llvm-project#60792 It turns out that Clang-IAS does not expand \@ uniquely in a translaition unit, and the XSA-426 change tickles this bug: <instantiation>:4:1: error: invalid symbol redefinition .L1_fill_rsb_loop: ^ make[3]: *** [Rules.mk:247: arch/x86/acpi/cpu_idle.o] Error 1 Extend DO_OVERWRITE_RSB with an optional parameter so C callers can mix %= in too, which Clang does seem to expand properly. Fixes: 63305e5 ("x86/spec-ctrl: Mitigate Cross-Thread Return Address Predictions") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> master commit: a2adacf master date: 2023-02-24 17:44:29 +0000
llvm/llvm-project#60792 It turns out that Clang-IAS does not expand \@ uniquely in a translaition unit, and the XSA-426 change tickles this bug: <instantiation>:4:1: error: invalid symbol redefinition .L1_fill_rsb_loop: ^ make[3]: *** [Rules.mk:247: arch/x86/acpi/cpu_idle.o] Error 1 Extend DO_OVERWRITE_RSB with an optional parameter so C callers can mix %= in too, which Clang does seem to expand properly. Fixes: 63305e5 ("x86/spec-ctrl: Mitigate Cross-Thread Return Address Predictions") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> master commit: a2adacf master date: 2023-02-24 17:44:29 +0000
\@
is the macro expansion count, and is supposed to be unique in each expansion inside a translation unit. It is commonly used to generate unique local named labels.However, Clang IAS doesn't get this quite right. https://godbolt.org/z/reedx7Gsr
Given:
GCC/Binutils, and Clang without IAS (not surprising - it hands of to GAS) expand
M
with 4 different numbers. However, Clang IAS does something a bit more weird.(warning - stdout and stderr are mixed in the following transcript, but it's reasonably easy to follow)
At the top level, it maintains an incrementing expansion count across separate
asm()
, so the 0 and 1 case expand correctly. However, when we come to the firstasm()
ina()
, the expansion count resets back to 0.This causes what should be unique local symbols to not be unique, and then suffer
error: invalid symbol redefinition
.For completeness, the second
asm()
ina()
also resets back to 0 again, which is why we end up with two duplicate symbol redefinitions.The text was updated successfully, but these errors were encountered: