[PATCH] D76962: [MC] Parse directives with arguments as macro arguments
Fangrui Song via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sun Mar 29 22:31:18 PDT 2020
MaskRay added a comment.
In D76962#1948922 <https://reviews.llvm.org/D76962#1948922>, @jcai19 wrote:
> This patch is not for GNU-compatibility. GNU's handling of spaces between directives and their arguments when expanding macros are confusing IMO -- it only supports selective directives. For example, it supports .inst (XXX) for aarch64, but not .section .foo or .space 0xf on x86 as you mentioned. For .section, if works if you do not have any space between .section and the argument, and surround it with parenthesis, but them will also be included as part of the section name, e.g. alternative_insn .section(.foo), .section(.bar) will work on gcc, but the object file will have (.foo) and (.bar) sections. I think we should either unconditionally support all of such directives, or not at all. I am fine with either option, and would happily close this if one of the workarounds is accepted into Linux.
You may not follow my comment. It is not that GNU as special cases certain directives, but rather it has a subtle `do_scrub_chars` rule.
.macro alternative_insn insn1, insn2
\insn1
\insn2
.endm
alternative_insn .section .foo, .section .bar # Error: too many positional arguments
alternative_insn ".section .foo", ".section .bar" # accepted
`arch/arm64/include/asm/sysreg.h` `__emit_inst(x)` really is likely a use of an unintentional GNU as "feature". The right solution is simply to quote the macro arguments. The rule as implemented by this patch can just make the clang vs GNU as differences more confusing.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D76962/new/
https://reviews.llvm.org/D76962
More information about the llvm-commits
mailing list