From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Subject: [PATCH] gas: retain whitespace between strings
Date: Tue, 22 Feb 2022 09:14:45 +0100 [thread overview]
Message-ID: <edad36de-f420-410d-5363-6be9d97896c0@suse.com> (raw)
Macro arguments may be separated by commas or just blanks. Macro
arguments may also be quoted (where one level of quotes is removed in
the course of determining the values for the respective formal
parameters). Furthermore this quote removal knows _two_ somewhat odd
escaping mechanisms: One, apparently in existence forever, is that a
pair of quotes counts as the escaping of a quote, with the pair being
transformed to a single quote in the course of quote removal. The other
(introduced by c06ae4f232e6) looks more usual on the surface in that it
deals with \" sequences, but it _retains_ the escaping \. Hence only the
former mechanism is suitable when the value to be used by the macro body
is to contain a quote. Yet this results in ambiguity of what "a""b" is
intended to mean; elsewhere (e.g. for .ascii) it represents two
successive string literals. However, in any event is the above different
from "a" "b": I don't think this can be viewed the same as "a""b" when
processing macro arguments.
Change the scrubber to retain such whitespace, by making the processing
of strings more similar to that of symbols. And indeed this appears to
make sense when taking into account that for quite a while gas has been
supporting quoted symbol names.
Taking a more general view, however, the change doesn't go quite far
enough. There are further cases where significant whitespace is removed
by the scrubber. The new testcase enumerates a few in its ".if 0"
section. I'm afraid the only way that I see to deal with this would be
to significantly simplify the scrubber, such that it wouldn't do much
more than collapse sequences of unquoted whitespace into a single blank.
To be honest problems in this area aren't really surprising when seeing
that there's hardly any checking of .macro use throughout the testsuite
(and in particular in the [relatively] generic tests under all/).
---
Partly RFC: While I did test this for x86, I didn't get around yet to
run a much wider set of tests.
--- a/gas/app.c
+++ b/gas/app.c
@@ -1088,10 +1088,10 @@ do_scrub_chars (size_t (*get) (char *, s
/* PUT didn't jump out. We could just break, but we
know what will happen, so optimize a bit. */
ch = GET ();
- old_state = 3;
+ old_state = 9;
}
- else if (state == 9)
- old_state = 3;
+ else if (state == 3)
+ old_state = 9;
else
old_state = state;
state = 5;
--- a/gas/testsuite/gas/all/gas.exp
+++ b/gas/testsuite/gas/all/gas.exp
@@ -461,6 +461,8 @@ if [is_elf_format] {
run_dump_test quoted-sym-names
+run_list_test macro "-alm"
+
run_list_test pr20312
load_lib gas-dg.exp
--- /dev/null
+++ b/gas/testsuite/gas/all/macro.l
@@ -0,0 +1,25 @@
+# This should match the output of gas -alm macro.s.
+
+.*: Assembler messages:
+.*:10: Error: too many positional arguments
+.*macro.s.*
+
+
+[ ]*[1-9][0-9]*[ ]+\.macro[ ]+m[ ]+arg1,[ ]*arg2[ ]*
+#...
+[ ]*[1-9][0-9]*[ ]+\.endm[ ]*
+[ ]*[1-9][0-9]*[ ]+
+[ ]*[1-9][0-9]*[ ]+m[ ]+1,[ ]*2
+[ ]*[1-9][0-9]*[ ]+.... 01[ ]+> .byte 1
+[ ]*[1-9][0-9]*[ ]+.... 02[ ]+> .byte 2
+[ ]*[1-9][0-9]*[ ]+m[ ]+3[ ]+4
+[ ]*[1-9][0-9]*[ ]+.... 03[ ]+> .byte 3
+[ ]*[1-9][0-9]*[ ]+.... 04[ ]+> .byte 4
+[ ]*[1-9][0-9]*[ ]+m[ ]+"5",[ ]*"6"
+[ ]*[1-9][0-9]*[ ]+.... 05[ ]+> .byte 5
+[ ]*[1-9][0-9]*[ ]+.... 06[ ]+> .byte 6
+[ ]*[1-9][0-9]*[ ]+m[ ]+"7"[ ]+"8"
+[ ]*[1-9][0-9]*[ ]+.... 07[ ]+> .byte 7
+[ ]*[1-9][0-9]*[ ]+.... 08[ ]+> .byte 8
+[ ]*[1-9][0-9]*[ ]+m[ ]+""[ ]+""[ ]+""
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/all/macro.s
@@ -0,0 +1,16 @@
+ .macro m arg1, arg2
+ .byte \arg1
+ .byte \arg2
+ .endm
+
+ m 1, 2
+ m 3 4
+ m "5", "6"
+ m "7" "8"
+ m "" "" ""
+
+ .if 0
+ m 1 +2
+ m (3) +4
+ m (5) (6)
+ .endif
next reply other threads:[~2022-02-22 8:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-22 8:14 Jan Beulich [this message]
2022-03-16 16:55 ` Nick Clifton
2022-03-17 8:20 ` Jan Beulich
2022-03-18 15:44 ` Nick Clifton
2022-03-21 7:16 ` Jan Beulich
2022-03-21 9:39 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edad36de-f420-410d-5363-6be9d97896c0@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).