On Fri, 19 Apr 2024 at 04:49, 姜智伟 <jian...@tecorigin.com> wrote:
>
> > 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?
thanks
-- PMM
