public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Andrew Waterman <andrew@sifive.com>,
	Jim Wilson <jim.wilson.gcc@gmail.com>,
	Nelson Chu <nelson@rivosinc.com>
Subject: [PATCH v2 2/7] RISC-V: drop "percent_op" parameter from my_getOpcodeExpression()
Date: Fri, 10 Mar 2023 10:26:00 +0100	[thread overview]
Message-ID: <366e4dcf-e273-a321-dd38-7adf4212c901@suse.com> (raw)
In-Reply-To: <ba68222c-7de6-280d-e98e-503e3c27addc@suse.com>

Both callers check for no relocations, so there's no point parsing for
some. Have the function pass percent_op_null into
my_getSmallExpression(). Note that there's no point passing
percent_op_itype: Elsewhere, especially when processing compressed alias
insns ahead of non-alias ones, this has the effect of avoiding "bad
expression" errors when another parsing pass may follow (and succeed).
Here, however, all alternative forms of an insn type will again start
with the same O4 or O2, so avoiding errors earlier on doesn't really
help. Plus constructs with a relocation specifier (as percent_op_itype
would permit) can't be specified anyway, as the scrubber eats the
whitespace between .insn's type and the O4 or O2 expression when that
starts with % or ( - i.e. these will be seen as e.g. "i%lo(x)", and
riscv_ip() looks only for whitespace when finding the end of a mnemonic.
---
There are pre-existing anomalies with redundant errors being reported,
up to one per insn form tried for a single source .insn or "normal"
insn. The change here merely widens that issue a little bit; the issue
wants getting under control elsewhere (and centrally).
---
v2: New.

--- a/gas/config/tc-riscv.c
+++ b/gas/config/tc-riscv.c
@@ -2285,7 +2285,7 @@ my_getSmallExpression (expressionS *ep,
 
 static size_t
 my_getOpcodeExpression (expressionS *ep, bfd_reloc_code_real_type *reloc,
-			char *str, const struct percent_op_match *percent_op)
+			char *str)
 {
   const struct opcode_name_t *o = opcode_name_lookup (&str);
 
@@ -2296,7 +2296,7 @@ my_getOpcodeExpression (expressionS *ep,
       return 0;
     }
 
-  return my_getSmallExpression (ep, reloc, str, percent_op);
+  return my_getSmallExpression (ep, reloc, str, percent_op_null);
 }
 
 /* Parse string STR as a vsetvli operand.  Store the expression in *EP.
@@ -3300,7 +3300,7 @@ riscv_ip (char *str, struct riscv_cl_ins
 	      switch (*++oparg)
 		{
 		case '4':
-		  if (my_getOpcodeExpression (imm_expr, imm_reloc, asarg, p)
+		  if (my_getOpcodeExpression (imm_expr, imm_reloc, asarg)
 		      || imm_expr->X_op != O_constant
 		      || imm_expr->X_add_number < 0
 		      || imm_expr->X_add_number >= 128
@@ -3317,7 +3317,7 @@ riscv_ip (char *str, struct riscv_cl_ins
 		  continue;
 
 		case '2':
-		  if (my_getOpcodeExpression (imm_expr, imm_reloc, asarg, p)
+		  if (my_getOpcodeExpression (imm_expr, imm_reloc, asarg)
 		      || imm_expr->X_op != O_constant
 		      || imm_expr->X_add_number < 0
 		      || imm_expr->X_add_number >= 3)


  parent reply	other threads:[~2023-03-10  9:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10  9:23 [PATCH v2 0/7] RISC-V/gas: insn operand parsing Jan Beulich
2023-03-10  9:25 ` [PATCH v2 1/7] RISC-V: minor effort reduction in relocation specifier parsing Jan Beulich
2023-03-10 11:24   ` Jan Beulich
2023-03-10  9:26 ` Jan Beulich [this message]
2023-03-10  9:26 ` [PATCH v2 3/7] RISC-V: avoid redundant and misleading/wrong error messages Jan Beulich
2023-03-10  9:27 ` [PATCH v2 4/7] RISC-V: don't recognize bogus relocations Jan Beulich
2023-03-10  9:27 ` [PATCH v2 5/7] RISC-V: relax post-relocation-operator separator expectation Jan Beulich
2023-04-25  8:13   ` Nelson Chu
2023-04-25  8:37   ` Andreas Schwab
2023-04-25  8:44     ` Nelson Chu
2023-04-25  8:52       ` Jan Beulich
2023-04-28  1:29         ` Nelson Chu
2023-04-28  6:05           ` Jan Beulich
2023-04-28  8:03             ` Fangrui Song
2023-05-11 11:27     ` Jan Beulich
2023-03-10  9:27 ` [PATCH v2 6/7] RISC-V: test for expected / no unexpected symbols Jan Beulich
2023-03-10  9:28 ` [PATCH v2 7/7] RISC-V: adjust logic to avoid register name symbols Jan Beulich
2023-04-25  8:40 ` [PATCH v2 0/7] RISC-V/gas: insn operand parsing Nelson Chu

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=366e4dcf-e273-a321-dd38-7adf4212c901@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew@sifive.com \
    --cc=binutils@sourceware.org \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=nelson@rivosinc.com \
    --cc=palmer@dabbelt.com \
    /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).