[RISC-V] Add g_GCShadowEnd to JIT_WriteBarrier_Table

[alpencolt]

lla pseudo instruction which used for access to g_GCShadowEnd in JIT_WriteBarrier implemented via PC-relative addressing. But when W^X enabled, copy of JIT_WriteBarrier is being created and this PC-related addressing is not valid, which cause crash.

This change moves address of g_GCShadowEnd to JIT_WriteBarrier_Table like others variables used in Write Barrier.

Part of #84834
cc @jakobbotsch @Maoni0 @wscho77 @HJLeee @JongHeonChoi @t-mustafin @clamp03 @gbalykov @tomeksowi

[alpencolt]

The similar issue should be in ARM64 since there is the same access to g_GCShadowEnd , while PREPARE_EXTERNAL_VAR expands to adrp which is also PC-relative.

@jkotas @Maoni0 JIT_UpdateWriteBarrierState puts new state to set of registers, e.g. for ARM64 it's x0-x7. But I can't find where they used after that. Are they used?

[jkotas]

JIT_UpdateWriteBarrierState puts new state to set of registers, e.g. for ARM64 it's x0-x7. But I can't find where they used after that. Are they used?

The registers are stored into the local literal pool here: JIT_UpdateWriteBarrierState puts new state to set of registers, e.g. for ARM64 it's x0-x7

[jkotas]

The similar issue should be in ARM64 since there is the same access to g_GCShadowEnd , while PREPARE_EXTERNAL_VAR expands to adrp which is also PC-relative.

I agree.

[alpencolt]

The registers are stored into the local literal pool here: JIT_UpdateWriteBarrierState puts new state to set of registers, e.g. for ARM64 it's x0-x7

Right, I've added g_GCShadowEnd to pool for RISC-V. But comment says (e.g. for ARM64):

    // x0-x7 will contain intended new state
    // x8 will preserve skipEphemeralCheck
    // x12 will be used for pointers

But do these x0-x7 used after that? I can't find it. Probably we could avoid copying of state to x0-x7 registers, if they aren't used at all.

[jkotas]

The registers are stored into the literal pool at the end of JIT_UpdateWriteBarrierState: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/arm64/asmhelpers.S#L258-L261

Are you suggesting that the method can always load a value into a register and then immediately store it into the literal pool? Yes, the code can be written that way, but I do not see anything wrong with how it is written today.

[jkotas]

Do you plan to do matching fix in the arm64 version as well?

[alpencolt]

Do you plan to do matching fix in the arm64 version as well?

Yes, I'll check on ARM64 environment and make separate PR

[jkotas]

Yes, I'll check on ARM64 environment and make separate PR

Thank you!