Teaching expression() to treat some operations specially

[Jan Beulich]

On 12.07.2022 08:47, Dmitry Selyutin wrote:
> 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.

I see. I have to admit that I don't know whether then it's the port's
or common code's responsibility to initialize X_md everywhere. I'm
sure Alan does ...

>>> 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".

No, that won't be parsed by expression(), the * will be taken off
elsewhere. AT&T syntax operand handling takes operands apart
"manually" (and uses expression() only on parts thereof), whereas
...

> Could you provide an example, please?

... you may find examples in Intel syntax handling (i386-intel.c),
which many years ago I did switch to actually going through
expression(). But: You may not get away without touching common
code, as unary and binary operators are treated separately, and
x86 uses it only for identifier-like unary operators. So it may
indeed be that * doesn't presently have a way to make it to
md_operator() when used in unary way.

Jan