[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