Page MenuHomeFreeBSD

DTrace aarch64: Avoid calling unwind_frame() in the probe context
ClosedPublic

Authored by domagoj.stolfa_gmail.com on May 8 2018, 8:37 PM.
Referenced Files
Unknown Object (File)
Sun, Nov 17, 8:49 AM
Unknown Object (File)
Oct 18 2024, 2:06 AM
Unknown Object (File)
Oct 18 2024, 2:06 AM
Unknown Object (File)
Oct 18 2024, 2:05 AM
Unknown Object (File)
Oct 17 2024, 11:29 PM
Unknown Object (File)
Oct 3 2024, 12:13 AM
Unknown Object (File)
Oct 1 2024, 1:09 PM
Unknown Object (File)
Sep 20 2024, 7:48 AM
Subscribers

Details

Summary

In DTrace, we require that we never reenter dtrace_probe() due to ordering constraints and avoiding recursion. On DTrace aarch64, namely when stack() was called, dtrace_getpcstack() would get called, which calls unwind_frame() from sys/arm64/arm64/unwind.c. It is because this function is quite short that it was inlined and therefore never instrumented by fbt, however, in the future a patch that enabled instrumentation of inlined functions could accidentally break DTrace on aarch64.

This patch addresses the issue by manually inlining the unwind_frame() function in dtrace_getpcstack().

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Ok for me, also tested on pine64

however, in the future a patch that enabled instrumentation of inlined functions could accidentally break DTrace on aarch64.

Was the problem found while working on such a patch? :)

however, in the future a patch that enabled instrumentation of inlined functions could accidentally break DTrace on aarch64.

Was the problem found while working on such a patch? :)

Unfortunately no 😢. If/when that day comes, you will be the first one to know, but don't let me hold you back from working on it :)

Why not just exclude it in fbt_provide_module_function? I'd prefer we keep the unwinding code together, maybe with a comment that it may be called from such a context.

Why not just exclude it in fbt_provide_module_function? I'd prefer we keep the unwinding code together, maybe with a comment that it may be called from such a context.

That works too. I guess the question is whether or not we would ever like to instrument the unwinding code being called. Excluding it from fbt means that we can never do so (DTrace already implements its own unwinding on amd64). I'm happy to submit a patch doing it the other way if people feel that it's the way to go as well.

Preemptively remove a redundant check for INKERNEL(fp).

Given the simplicity of this unwinding code, I think it's reasonable to just keep it inline like we do on amd64. DTrace reimplements quite a lot of "standard" code for the same reason as we do here.

This revision was not accepted when it landed; it landed in state Needs Review.May 12 2018, 3:35 PM
This revision was automatically updated to reflect the committed changes.