[PATCH] testsuites: Fix RISC-V tests with 'nop' instruction.

[Jiawei]

In 2025/9/10 22:44, Nelson Chu wrote:
>
>
> On Wed, Sep 10, 2025 at 8:59 PM Jan Beulich <jbeulich@suse.com> wrote:
>
>     On 10.09.2025 14:09, Jiawei wrote:
>     > This patch forces tests containing 'nop'(0x13) instructions to
>     specify the
>     > as parameter. The default as parameter is rv64gc will generation
>     compressed
>     > instruction 'c.nop'(0x1) and broken the result as expected.
>
>     I don't follow this explanation. There's no breakage right now,
>     and you also
>     don't alter any of the test expectations. Was the 2nd sentence
>     maybe intended
>     to start "If the default gas setting is rv64gc ..."? (I.e. if an
>     override of
>     DEFAULT_RISCV_ARCH_WITH_EXT was in effect.) 
>
>
> Yeah I guess that's the problem, but the weird thing is I suppose the 
> regressions of riscv-gnu-toolchain should test it, but I don't get any 
> failures...  I think it's fine to make test cases passed for specific 
> DEFAULT_RISCV_ARCH_WITH_EXT build, but force them to rv64i means we 
> won't test rv32 for those test cases, which I think original we also 
> wants rv32 were tested.  Does the .option norvc directives work for 
> those testcase?  It seems only the difference between nop and c.nop, 
> and we don't want c.nop breaks the test cases.
>
> For the dis-partial-insn-byte, rv64i generates nop, and rv64gc 
> generates c.nop, which breaks the "objdump --start-address 0 
> --stop-address 1 -d", the former shows .byte 0x13, but the latter 
> shows .byte 0x01.


Yes, that's the problem, before the riscv-gnu-toolchain update, 
--with-arch option will not be passed into binutils part, but currently 
it does,

https://github.com/riscv-collab/riscv-gnu-toolchain/commit/1faa77ffe8daec705aa1ef266e944c554d838881

so some test will show compressed result and come into fail.

Thanks for your hint, the current revision is indeed one-sided. I think 
maybe add .option norvc in assemble file is a better choice.


BR,

Jiawei


>     If so, is NOP really the only thing
>     we would need to be concerned of?
>
>
> Well...  Yeah probably more need to be concerned.  Hi Jiawei, if you 
> have time, could you please help to check out why riscv-gnu-toolchain 
> regressions don't cause these problems? I remember that when muti-lib 
> is not built, the toolchains should be built by --with-arch and 
> --with-isa-spec configure options.  Thanks :-)
>
> Nelson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20250911/0b4d6016/attachment.htm>