Re: RISC-V: mapping symbols vs "unimpl"

[Jan Beulich <jbeulich@suse.com>]

On 14.02.2022 12:24, Nelson Chu wrote:
> On Mon, Feb 14, 2022 at 6:35 PM Andrew Waterman <andrew@sifive.com> wrote:
>> On Mon, Feb 14, 2022 at 12:27 AM Jan Beulich via Binutils
>> <binutils@sourceware.org> wrote:
>>> Do you have any suggestion how to encode a spec-conforming "unimpl",
>>> which I want to be part of my own disassembler's test cases (in
>>> particular the 0xffff0000 form)? Since the commit introducing the
>>> mapping symbols refers to Arm, I'd like to point out that their .insn
>>> equivalents allow to encode entirely arbitrary instruction forms. But
>>> of course I understand that RISC-V's insn length encoding scheme is
>>> somewhat in conflict with this.
> 
> We are used to checking if the instruction is valid or not for the
> .insn directive.  So this made me think - maybe we should allow .insn
> to encode any instruction, including illegal formats, just like what
> Arm/AArch do as you mentioned.
> 
>>> Two further remarks: Even ".insn ci ..." cannot be used, not even for
>>> forms with the high 16 bits not all set (which again the main opcode
>>> restriction would get in the way of): Already just temporarily
>>> enabling RVC causes the RVC bit to be set in the ELF header flags.
>>> Yet with that bit set 0xffff0000 is actually a 16-bit insn 0x0000
>>> followed by a wider insn with the low 16 bits all set. IOW this
>>> conflicts with the spec's wording of "minimal length insn with the
>>> low 16 bits all zero".
> 
> For now you probably can write 0xffff0000 by two .insn directives.
> For example, .insn 0x0 + .insn 0xffff, and then you should get
> something like,
> 
> Disassembly of section .text:
> 
> 0000000000000000 <.text>:
>    0:   0000                    unimp
>    2:   ffff                    .2byte  0xffff
> 
> Anyway, this is just a workaround.  I will find relevant people to
> discuss whether the .insn directive should be allowed to encode an
> illegal format.

Hmm, interesting. I wasn't aware of these alternative forms of
.insn. But I wonder in how far I can actually rely on the present
behavior: ".insn 0xffff" emitting a 16-bit value does not really
form a valid 16-bit insn. I'd rather expect the "value conflicts
with instruction length" in this case. And if a 16-bit insn is
emitted, I'd expect a check for RVC being enabled, which in turn
would have led to RVC being recorded in the header (creating the
same problem as mentioned before again).

But yes, for the immediate purpose with 2.38, "utilizing" its
shortcomings, I should be able to use this approach.

Looking at riscv_ip_hardcode() I also notice that

	.insn 8, 0x3f

wrongly triggers that very error, due to the undefined behavior of
the shift in this case.

Jan