> 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.
static void init_ts_info(OptContext *ctx, TCGTemp *ts)
{
size_t idx = temp_idx(ts);
TempOptInfo *ti;
if (test_bit(idx, ctx->temps_used.l)) {
return;
}
...
I can fix this segmentation fault by applying the modification above,
and it seems more logical in terms of code logic to match the allocation and
indexing of TCGTemp.
Ths
