[jdk18] RFR: 8272058: 25 Null pointer dereference defect groups in 4 files
Gerard Ziemski
gziemski at openjdk.java.net
Wed Dec 22 17:49:24 UTC 2021
On Mon, 20 Dec 2021 20:50:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
> A small refactoring to resolve a Parfait complaint about the return value from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)`
> on AARCH64. The logic that supports returning `nullptr` as the target addr for
> a particular instruction is moved from
> `MacroAssembler::target_addr_for_insn(address insn_addr, unsigned insn)` to
> `MacroAssembler::target_addr_for_insn_allow_null_ret(address insn_addr, unsigned insn)`.
> A couple of `target_addr_for_insn()` call sites that can tolerate a `nullptr` are
> converted to use `target_addr_for_insn_allow_null_ret()`.
>
> This fix has been tested with Mach5 Tier[1-3].
I don't understand the underlying code, but from a big picture point of view, splitting the call into "null not allowed" and "null allowed" makes sense. If the testing came back fine, then that's the best we can do, without asking someone who wrote this code to chime in.
Just one question: why do we need the "null allowed" version here?
void NativeMovRegMem::verify() {
#ifdef ASSERT
address dest = MacroAssembler::target_addr_for_insn_allow_null_ret(instruction_address());
#endif
}
-------------
Marked as reviewed by gziemski (Committer).
PR: https://git.openjdk.java.net/jdk18/pull/51
More information about the hotspot-runtime-dev
mailing list