From: Dmitry Selyutin <ghostmansd@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: lkcl <luke.leighton@gmail.com>,
Binutils <binutils@sourceware.org>,
Alan Modra <amodra@gmail.com>
Subject: Re: Teaching expression() to treat some operations specially
Date: Tue, 12 Jul 2022 09:47:08 +0300 [thread overview]
Message-ID: <CAMqzjesy5LxY0ivJJmzC6AeOkqGY2FE9fs8=JYREoL+JA6bfkg@mail.gmail.com> (raw)
In-Reply-To: <473de1ae-ab00-357c-56e1-a12e2eab779a@suse.com>
On Tue, Jul 12, 2022 at 9:25 AM Jan Beulich <jbeulich@suse.com> wrote:
> May I ask which other struct fields are consumed and where? It is
> my understanding that for O_register other fields simply are
> invalid ...
The check takes a look at the X_md field. I assume this is a
PPC-specific tweak, though.
The check we fail to pass after the call to expression() is here:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c;h=5015777d60061e61ffe4c78591b793862919c769;hb=HEAD#l3468
We do indeed tune X_md field in several places to recognize the type
of the register.
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c;h=5015777d60061e61ffe4c78591b793862919c769;hb=HEAD#l857
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c;h=5015777d60061e61ffe4c78591b793862919c769;hb=HEAD#l915
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c;h=5015777d60061e61ffe4c78591b793862919c769;hb=HEAD#l938
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c;h=5015777d60061e61ffe4c78591b793862919c769;hb=HEAD#l952
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c;h=5015777d60061e61ffe4c78591b793862919c769;hb=HEAD#l966
I assume this logic is intended; X_md is listed as a machine-dependent
field, so PPC port took the liberty to re-use it for this information.
>
> > However, about using expression() in md_operand(), there's another question.
> > One of particular cases we're interested in is extending operands with
> > the vector notation.
> > For example, *%r3 would mean "vector register %r3, same as %r3, but
> > operating on a vector".
> > This is the code we're currently using; what'd be the safe way to
> > replace expression()?
>
> Maybe you want to recognize * as a unary operator, assigning it
> one of the O_md<N> values?
Yes, I think this would be much a better option! But I didn't manage
to get md_operator working with * symbol...
It seems by the time the execution arrives at md_operator call site, *
is already consumed by the operand() logic.
Perhaps I should tweak lex_type with LEX_NAME flag respectively?
This for sure should work somehow, considering that x86 has
expressions like "jmp *%rax".
Could you provide an example, please?
Anyway, even if we teach md_operator to recognize * operator, this
still leaves the question of macros open.
Regardless of the vector notation used, we're unable to do things like
`.set XXX, %r3`.
FWIW, the "better" version of the patch to expr.c would be this:
diff --git a/gas/expr.c b/gas/expr.c
index f4ea24717d..cf8fa961eb 100644
--- a/gas/expr.c
+++ b/gas/expr.c
@@ -1341,17 +1341,12 @@ operand (expressionS *expressionP, enum expr_mode mode)
/* If we have an absolute symbol or a reg, then we know its
value now. */
segment = S_GET_SEGMENT (symbolP);
- if (mode != expr_defer
- && segment == absolute_section
- && !S_FORCE_RELOC (symbolP, 0))
+ if ((mode != expr_defer
+ && segment == absolute_section
+ && !S_FORCE_RELOC (symbolP, 0))
+ || (mode != expr_defer && segment == reg_section))
{
- expressionP->X_op = O_constant;
- expressionP->X_add_number = S_GET_VALUE (symbolP);
- }
- else if (mode != expr_defer && segment == reg_section)
- {
- expressionP->X_op = O_register;
- expressionP->X_add_number = S_GET_VALUE (symbolP);
+ *expressionP = *symbol_get_value_expression (symbolP);
}
else
{
This is assuming that the patch is correct at all, of course.
--
Best regards,
Dmitry Selyutin
next prev parent reply other threads:[~2022-07-12 6:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-09 16:47 Dmitry Selyutin
2022-07-11 1:01 ` Alan Modra
2022-07-11 2:33 ` lkcl
2022-07-11 3:08 ` Alan Modra
2022-07-11 14:28 ` Dmitry Selyutin
2022-07-11 19:13 ` Dmitry Selyutin
2022-07-11 23:37 ` Alan Modra
2022-07-12 4:18 ` Dmitry Selyutin
2022-07-12 6:25 ` Jan Beulich
2022-07-12 6:47 ` Dmitry Selyutin [this message]
2022-07-12 6:57 ` Jan Beulich
2022-07-12 8:50 ` Dmitry Selyutin
2022-07-12 10:44 ` Jan Beulich
2022-07-12 11:17 ` Dmitry Selyutin
2022-07-12 11:39 ` Jan Beulich
2022-07-12 9:01 ` Dmitry Selyutin
2022-07-12 6:58 ` Dmitry Selyutin
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='CAMqzjesy5LxY0ivJJmzC6AeOkqGY2FE9fs8=JYREoL+JA6bfkg@mail.gmail.com' \
--to=ghostmansd@gmail.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=jbeulich@suse.com \
--cc=luke.leighton@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).