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
next 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).