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

[Nelson Chu]

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.


> 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/20250910/856ecc3b/attachment.htm>