> > > On 4/18/24 03:27, Zhiwei Jiang wrote:
> > > > Sometimes, when the address of the passed TCGTemp *ts variable is the
> > > > same as tcg_ctx,
> > >
> > > Pardon? When would TCGTemp *ts == TCGContext *tcg_ctx?
> > >
> > >
> > > > the index calculated in the temp_idx function, i.e., ts -
> > > > tcg_ctx->temps,
> > > > can result in a particularly large value, causing overflow in the
> > > > subsequent array access.
> > >
> > > Or, assert:
> > >
> > > size_t temp_idx(TCGTemp *ts)
> > > {
> > > ptrdiff_t n = ts - tcg_ctx->temps;
> > > assert(n >= 0 && n < tcg_ctx->nb_temps);
> > > return n;
> > > }
> > >
> > > > static inline TCGTemp *tcgv_i32_temp(TCGv_i32 v)
> > > > {
> > > > - return (void *)tcg_ctx + (uintptr_t)v;
> > > > + return (void *)tcg_ctx->temps + (uintptr_t)v;
> > > > }
> > >
> > > This will generate 0 for the first temp, which will test as NULL.
> >
> > Hi Richard:
> > You can reproduce this issue on the latest upstream QEMU version. Using the
> > RISC-V QEMU version,
> > if we compile a test program with the first instruction being '.insn r 0xf,
> > 2, 0, x0, x0, x0',that is a RISC-V CBO instruction,
> > qemu will crash with a segmentation fault upon execution.
> >
> > When the first instruction in the program is a CBO instruction, temp_idx
> > in init_ts_info func returns a very large value,
> > causing the subsequent test_bit function to access out-of-bounds memory.
>
> I feel like this might be a bug elsewhere. Can you provide
> a repro binary and command line?The test file has been attached with RISCV CBO instruction as the first instruction to execute, with command-line arguments as ./build/qemu-system-riscv64 -M virt -smp 1 -nographic -bios crash_test.bin
crash_test.bin
Description: Binary data
