RFR: 8364150: RISC-V: Leftover for JDK-8343430 removing old trampoline call [v2]
Fei Yang
fyang at openjdk.org
Mon Jul 28 13:13:57 UTC 2025
On Mon, 28 Jul 2025 12:57:41 GMT, Hamlin Li <mli at openjdk.org> wrote:
>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Comment
>
> src/hotspot/cpu/riscv/nativeInst_riscv.cpp line 116:
>
>> 114: if (code->is_nmethod()) {
>> 115: assert(dest != nullptr, "Sanity");
>> 116: MacroAssembler::pd_patch_instruction_size(call_addr, dest);
>
> `dest` here is the reloc call desitnation, ie. the dest stored in the stub, and it should be able to reach anywhere in the address space.
> The patch here should patch the `auipc + jalr` to the address of this stub, rather than `dest`?
Yes, the `dest` param here holds the address of this stub.
In `CallRelocation::fix_relocation_after_move`, we first get the `callee` address by calling `pd_call_destination` which delegates work to `NativeCall::reloc_destination` for a NativeCall. And we have modified `NativeCall::reloc_destination` to return the stub address in this PR at the same time. So `callee` will hold the stub address. Immediatedly after that, `callee` is passed to `pd_set_call_destination` which delegates work to `NativeCall::reloc_set_destination`. Make sense?
void CallRelocation::fix_relocation_after_move(const CodeBuffer* src, CodeBuffer* dest) {
// Usually a self-relative reference to an external routine.
// On some platforms, the reference is absolute (not self-relative).
// The enhanced use of pd_call_destination sorts this all out.
address orig_addr = old_addr_for(addr(), src, dest);
address callee = pd_call_destination(orig_addr); <=========== callee is stub address
// Reassert the callee address, this time in the new copy of the code.
pd_set_call_destination(callee); <=========== callee passed as param
}
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26495#discussion_r2236392322
More information about the hotspot-compiler-dev
mailing list