Bug 203941
| Summary: | arm64 IMPLEMENT ME: dtrace_toxic_ranges | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Ed Maste <emaste> |
| Component: | kern | Assignee: | Andrew Turner <Andrew> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | br |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | arm64 | ||
| OS: | Any | ||
| Bug Depends on: | |||
| Bug Blocks: | 203349 | ||
And for quick reference: /* * DTrace Toxic Ranges * * DTrace supports safe loads from probe context; if the address turns out to * be invalid, a bit will be set by the kernel indicating that DTrace * encountered a memory error, and DTrace will propagate the error to the user * accordingly. However, there may exist some regions of memory in which an * arbitrary load can change system state, and from which it is impossible to * recover from such a load after it has been attempted. Examples of this may * include memory in which programmable I/O registers are mapped (for which a * read may have some implications for the device) or (in the specific case of * UltraSPARC-I and -II) the virtual address hole. The platform is required * to make DTrace aware of these toxic ranges; DTrace will then check that * target addresses are not in a toxic range before attempting to issue a * safe load. */ |
On arm64, root@:~ # kldload dtraceall IMPLEMENT ME: dtrace_toxic_ranges Looking at sys/cddl/dev/dtrace/*/dtrace_subr.c I see only i386 setting a toxic range: (*func)(0, kernelbase); All others are either the no-op * No toxic regions? or printf("IMPLEMENT ME: dtrace_toxic_ranges\n");