Teaching expression() to treat some operations specially

[Dmitry Selyutin]

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