We’ve noticed that many of the stack size analysis flags fail to report usage about the UnsafeStack when SafeStack is enabled. For example, Fuchsia compiles w/ SafeStack by default, and using flags like
-fstack-usage ignore the allocations on the UnsafeStack. Our engineers were surprised by this, since they assumed the stack usage analysis would account for data across all stacks, and not just the machine stack.
While it is possible to disable SafeStack and get the useful results, it doesn’t seem like this is an intentional choice. Moreover, it forces users into an additional build configuration to get a single diagnostic. I think many users would be surprised by this behavior, especially since I could not find anything documenting this limitation. In general, I would expect users opting into these diagnostics are concerned with determining if a function is using a significant amount of stack memory regardless if the stack is split by a security transform.
Looking at the code in the SafeStack passes, it appears that the size of the static portion of the UnsafeStack frame is readily available when the SafeStackLayout is calculated. If that information was available when the stack size related checks were performed, it would be possible to support these split stack configurations.
Is there a fundamental problem with making the UnsafeStack size available to the backend, so that the analysis results can be surfaced in a more meaningful way when using SafeStack? I would think a metadata tag or attribute on a function would be sufficient to ensure that data isn’t lost.
I have a quick prototype for this on Phabricator: ⚙ D119996 [safestack] Support safestack in stack size diagnostics
Would there be support for changing the existing behavior when SafeStack and the related diagnostics are enabled?