[Bug binutils/25750] GNU as has inconsistent behavior when expanding .macro that takes as input directives with arguments
https://sourceware.org/bugzilla/show_bug.cgi?id=25750 --- Comment #8 from Jian Cai --- Hi Nick, Thanks for the feedback. First all of, apology and correction to the code example I came up with in https://sourceware.org/bugzilla/show_bug.cgi?id=25750#c4. It should be .macro foo insn1 insn2 \insn1 \insn2 .endm foo .section .sec1, .section .sec2 > Do you mean that if a macro's argument is the string ".inst" then it will treat any text that follows on the same line as being part of the same argument ? If so, then is this special treatment reserved only for macro arguments that start with ".inst" ? What I meant was for gcc to treat the macro expansion in this example as foo ".section .sec1", ".section .sec2", albeit without the quotes, i.e. considering .section .sec1 as the argument for insn1, and .section .sec2 as the argument for insn2. Currently, as treats foo .inst (XXX), .inst (YYY) as foo ".inst (XXX)", ".inst (YYY)" but not some others, such as foo .section .sec1, .section .sec2. All in all I don't think this is a major issue and we have different ways to work around it, so it's completely understandable if this remains what it is on gcc. I just figured it may be worth reporting this issue to upstream in case there is any interest to fix it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25750] GNU as has inconsistent behavior when expanding .macro that takes as input directives with arguments
https://sourceware.org/bugzilla/show_bug.cgi?id=25750 Jian Cai changed: What|Removed |Added Resolution|FIXED |WONTFIX -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25750] GNU as has inconsistent behavior when expanding .macro that takes as input directives with arguments
https://sourceware.org/bugzilla/show_bug.cgi?id=25750 Jian Cai changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Jian Cai --- Thanks Nick and Fangrui. Going through all the comments, it seems keeping the status quo is a better choice to keep existing (especially legacy) code work. Thank you all for the discussion and will close this issue now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25750] GNU as has inconsistent behavior when expanding .macro that takes as input directives with arguments
https://sourceware.org/bugzilla/show_bug.cgi?id=25750 --- Comment #6 from Jian Cai --- > So this: > > .macro foo insn1 insn2 > \insn1 \insn2 > .endm > > foo .section .sec1 > > Does work. Thanks for the suggestion. I found this issue while working on https://github.com/ClangBuiltLinux/linux/issues/939. Essentially, the following case assembled with arm-linux-gnueabihf-gcc but not clang. $ cat bad.s .macro alternative_insn insn1 .endm alternative_insn .inst (0x0) There were several ways to make it work with clang, including removing the space between .inst and its argument, quoting the directive and its arguments, and now using vararg as you suggested. I made an LLVM patch for (https://reviews.llvm.org/D76962), which will make clang's integrated assembler to treat .inst and its arguments as one macro argument in the above example. It did not go though upstream review as it would create mismatch between clang and gcc, so I am curious if gcc is interested to have more general support, so that code like the example in Comment 4 will work without being rewritten. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25750] New: GNU as has inconsistent behavior when expanding .macro that takes as input directives with arguments
https://sourceware.org/bugzilla/show_bug.cgi?id=25750 Bug ID: 25750 Summary: GNU as has inconsistent behavior when expanding .macro that takes as input directives with arguments Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: caij2003 at gmail dot com Target Milestone: --- Handling of spaces between directives and their arguments when expanding macros is not consistent in GNU as -- it only supports selective directives. For example, the following code assembled with aarch64-linux-gnu-gcc, .macro foo insn \insn .endm foo .inst (XXX) However, if we replace the argument of the macro expansion with another directive, such as "foo .section .sec1", it will fail. This is the case on x86 as well. Removing the space and surround the section name with parenthesis will work, i.e. "foo .section(.sec1)". But the section name is (.sec1) instead of .sec1 as intended. Not sure if this is intended but it introduces some confusion IMO. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25750] GNU as has inconsistent behavior when expanding .macro that takes as input directives with arguments
https://sourceware.org/bugzilla/show_bug.cgi?id=25750 --- Comment #2 from Jian Cai --- Hi Nick, Thank you for the information. I used gas 2.33.1 $ as -v GNU assembler version 2.33.1 (aarch64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.33.1 Does :vararg work for multiple arguments? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25750] GNU as has inconsistent behavior when expanding .macro that takes as input directives with arguments
https://sourceware.org/bugzilla/show_bug.cgi?id=25750 --- Comment #4 from Jian Cai --- Sorry I just realized my question was misleading. What I really meant was if vararg would work on a macro taking as input multiple directives with arguments, such as the one below. vararg seemed to not work with such case in my experiment. .macro foo insn1, insn2 \insn1 \insn2 .endm foo .section .sec1 foo .section .sec2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27519] GNU AS does not support SUBSPL syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=27519 Jian Cai changed: What|Removed |Added Version|unspecified |2.35.1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27519] GNU AS does not support SUBSPL syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=27519 Jian Cai changed: What|Removed |Added Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jian Cai --- It worked! Thanks for the clarification. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27519] GNU AS does not support SUBSPL syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=27519 Jian Cai changed: What|Removed |Added URL||https://crbug.com/1184997 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27519] New: GNU AS does not support SUBSPL syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=27519
Bug ID: 27519
Summary: GNU AS does not support SUBSPL syntax
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: caij2003 at gmail dot com
Target Milestone: ---
According to "ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition",
the subtraction instruction of registers has the following syntax:
SUB{S}{}{} {,} , {, }
However, GNU AS does not support such syntax:
$ cat foo.s
subspl r3, r3, r8
$ arm-linux-gnueabihf-as foo.s -o gcc.o
foo.s: Assembler messages:
foo.s:2: Error: bad instruction `subspl r3,r3,r8'
In the above code, PL is is one of possible condition codes for in the SUB
instruction. However, GAS supports a slightly different syntax:
$ cat bar.s
subpls r3, r3, r8
$ arm-linux-gnueabihf-as bar.s -o gcc.o
$ arm-linux-gnueabihf-objdump -d gcc.o
gcc.o: file format elf32-littlearm
Disassembly of section .text:
<.text>:
0: 50533008subspl r3, r3, r8
Note objdump prints subspl instead of subpls. Clang only supports the official
syntax, so code written with the GNU syntax would not be compatible with Clang.
Links:
https://developer.arm.com/documentation/ddi0406/cd
--
You are receiving this mail because:
You are on the CC list for the bug.
