public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Cc: Alan Modra <amodra@gmail.com>,
	Peter Bergner <bergner@vnet.ibm.com>,
	Geoff Keating <geoffk@geoffk.org>,
	"H.J. Lu" <hjl.tools@gmail.com>
Subject: [PATCH] gas: equates of registers
Date: Fri, 21 Apr 2023 14:17:54 +0200	[thread overview]
Message-ID: <4c40b0d1-8375-9284-cfaf-ce63b8df1b9b@suse.com> (raw)

There are two problems: symbol_equated_p() doesn't recognize equates of
registers, and S_CAN_BE_REDEFINED() goes by section rather than by
expression type. Both together undermine .eqv and .equiv clearly meaning
to guard the involved symbols against re-definition (both ways).

To compensate pseudo_set() now using O_symbol and S_CAN_BE_REDEFINED()
now checking for O_register,
- for targets creating register symbols through symbol_{new,create}() ->
  symbol_init() -> S_SET_VALUE() (alpha, arc, dlx, ia64, m68k, mips,
  mmix, tic4x, tic54x, plus anything using cgen or itbl-ops), have
  symbol_init() set their expressions to O_register,
- x86'es parse_register() also can't go by section anymore when
  trying to "look through" equates; probably symbol_equated_p() should
  have been used there from the beginning, if only that had worked for
  equates of registers,
- ppc's md_assemble() needs to "look through" equates (which also helps
  transitive forward equates).

This was uncovered by code reported in PR gas/30274 (duplicating
PR gas/30272), except that there .eqv was used when really .equ was
meant. Therefore that bug report is addressed here only in so far as
gas wouldn't crash anymore; the code there still won't assemble
successfully, just that now the issues there are properly diagnosed.
---
Clearly equates of constants have the same issue of not being viewed as
equates by symbol_equated_p(). Changing that isn't the purpose of the
change here, and I'm afraid is also yet more likely to trigger issues
elsewhere.

For ppc I wonder whether the "looking through" equates really should be
limited to registers only: This might be as applicable to constants
(including O_big), and finding e.g. O_illegal right away might be
helpful too.

If the setting to O_register was to occur in S_SET_VALUE() instead of in
symbol_init() (which overall would seem more consistent), all callers
would need to make sure that they call S_SET_SEGMENT() (if at all) ahead
of S_SET_VALUE(), not afterwards.

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -13832,11 +13832,11 @@ parse_register (const char *reg_string,
       input_line_pointer = buf;
       get_symbol_name (&name);
       symbolP = symbol_find (name);
-      while (symbolP && S_GET_SEGMENT (symbolP) != reg_section)
+      while (symbolP && symbol_equated_p (symbolP))
 	{
 	  const expressionS *e = symbol_get_value_expression(symbolP);
 
-	  if (e->X_op != O_symbol || e->X_add_number)
+	  if (e->X_add_number)
 	    break;
 	  symbolP = e->X_add_symbol;
 	}
--- a/gas/config/tc-ppc.c
+++ b/gas/config/tc-ppc.c
@@ -3475,6 +3475,28 @@ md_assemble (char *str)
       str = input_line_pointer;
       input_line_pointer = hold;
 
+      /* "Look through" register equates.  */
+      if (ex.X_op == O_symbol)
+	{
+	  symbolS *sym = ex.X_add_symbol;
+	  offsetT acc = ex.X_add_number;
+	  const expressionS *e = symbol_get_value_expression (sym);
+
+	  while (symbol_equated_p (sym))
+	    {
+	      if (e->X_op != O_symbol)
+		break;
+	      sym = e->X_add_symbol;
+	      acc += e->X_add_number;
+	      e = symbol_get_value_expression (sym);
+	    }
+	  if (e->X_op == O_register)
+	    {
+	      ex = *e;
+	      ex.X_add_number += acc;
+	    }
+	}
+
       if (ex.X_op == O_illegal)
 	as_bad (_("illegal operand"));
       else if (ex.X_op == O_absent)
--- a/gas/read.c
+++ b/gas/read.c
@@ -4000,6 +4000,10 @@ pseudo_set (symbolS *symbolP)
 	  return;
 	}
 #endif
+      /* Make sure symbol_equated_p() recognizes the symbol as an equate.  */
+      exp.X_add_symbol = make_expr_symbol (&exp);
+      exp.X_add_number = 0;
+      exp.X_op = O_symbol;
       symbol_set_value_expression (symbolP, &exp);
       S_SET_SEGMENT (symbolP, reg_section);
       set_zero_frag (symbolP);
--- a/gas/symbols.c
+++ b/gas/symbols.c
@@ -387,6 +387,8 @@ symbol_init (symbolS *symbolP, const cha
     }
 
   S_SET_VALUE (symbolP, valu);
+  if (sec == reg_section)
+    symbolP->x->value.X_op = O_register;
 
   symbol_clear_list_pointers (symbolP);
 
@@ -2463,7 +2465,7 @@ S_CAN_BE_REDEFINED (const symbolS *s)
     return (((struct local_symbol *) s)->frag
 	    == &predefined_address_frag);
   /* Permit register names to be redefined.  */
-  return s->bsym->section == reg_section;
+  return s->x->value.X_op == O_register;
 }
 
 int

             reply	other threads:[~2023-04-21 12:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-21 12:17 Jan Beulich [this message]
2023-04-24  0:05 ` Alan Modra
2023-04-24  8:12   ` Jan Beulich
2023-04-26  7:02     ` Alan Modra

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=4c40b0d1-8375-9284-cfaf-ce63b8df1b9b@suse.com \
    --to=jbeulich@suse.com \
    --cc=amodra@gmail.com \
    --cc=bergner@vnet.ibm.com \
    --cc=binutils@sourceware.org \
    --cc=geoffk@geoffk.org \
    --cc=hjl.tools@gmail.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).