fix debug.kdb.enter=1 with dtrace-enabled kernel

[br]

Summary

Fix debug enter with "sysctl debug.kdb.enter=1" when dtrace compiled-in to the kernel.

The change to dtrace_subr.c is optimization only and is not mandatory for this patch.

Test Plan

Tested with this one-liner:
dtrace -n 'fbt::malloc:entry { @[stack()] = count(); }'

Other one-liners are available here:
https://wiki.freebsd.org/DTrace/One-Liners

[br]

Add context

[jrtc27]

This is not a RISC-V-specific thing; every architecture currently ignores the return value of dtrace_invop_jump_addr.

[jhb]

Hmm, I'm curious if this breaks on other platforms then.

[br]

In D24018#528102, @jhb wrote:

Hmm, I'm curious if this breaks on other platforms then.

This does not break on arm64 because brk instruction != FBT_PATCHVAL.

[markj]

In D24018#528102, @jhb wrote:

Hmm, I'm curious if this breaks on other platforms then.

It seems to also be broken on !x86. i386 and amd64 return control if dtrace determines that it wasn't the source of the breakpoint.

sys/cddl/dev/dtrace/riscv/dtrace_subr.c

297 ↗

(On Diff #69361)

I'd think we should panic in this case, at least with INVARIANTS enabled.

[br]

Add a call to panic()

[markj]

sys/riscv/riscv/trap.c

278 ↗

(On Diff #69423)

Since you're changing this line, it should be updated to compare with NULL instead of 0.

[br]

Compare to NULL

[br]

Fix spelling

[jrtc27]

sys/cddl/dev/dtrace/riscv/dtrace_subr.c

298 ↗

(On Diff #69479)

"doesn't"

[brooks]

Any reason not to land this?