On 25.06.2024 15:51, Oleksii Kurochko wrote:
> The .insn directive appears to check that the byte pattern is a known
> extension, where .4byte doesn't.
Support for specifying "raw" insns was added only in 2.38. Moving away
from .insn has other downsides (which may or may not matter here, but
that would want discussing). But: Do we really need to move away? Can't
you use .insn with operands that the older gas supports, e.g.
.insn r MISC_MEM, 0, 0, x0, x0, x16
? I'm sorry, the oldest RISC-V gas I have to hand is 2.39, so I couldn't
double check that 2.35 would grok this. From checking sources it should,
though.
> The following compilation error occurs:
> ./arch/riscv/include/asm/processor.h: Assembler messages:
> ./arch/riscv/include/asm/processor.h:70: Error: unrecognized opcode
> `0x0100000F'
> In case of the following Binutils:
> $ riscv64-linux-gnu-as --version
> GNU assembler (GNU Binutils for Debian) 2.35.2
In patch 6 you say 2.39. Why is 2.35.2 suddenly becoming of interest?
> --- a/xen/arch/riscv/include/asm/processor.h
> +++ b/xen/arch/riscv/include/asm/processor.h
> @@ -67,7 +67,7 @@ static inline void cpu_relax(void)
> __asm__ __volatile__ ( "pause" );
> #else
> /* Encoding of the pause instruction */
> - __asm__ __volatile__ ( ".insn 0x0100000F" );
> + __asm__ __volatile__ ( ".byte 0x0100000F" );
> #endif
In the description you (correctly) say .4byte; why is it .byte here?
Does this build at all?
Jan
