You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Being able to output JSON, instead of a .dot file, has a few uses:
it makes our unit tests more reliable: we would be able to use an API instead of text extraction / comparison
it lets other people perform post-analysis (using cargo xtask for example) relevant to their project. some use cases:
does the call graph that stems function X contain a cycle? e.g. does defmt::info-ing a recursive struct requires recursion?
can stack usage be upper bounded for this application? use CI to ensure it stays that way
is this application free from indirect function calls?
RTIC apps contain disconnected components due to the presence of interrupt handlers thus stack cannot be upper bounded for the whole app. with call-stack data + RTIC metadata it should be possible to compute the whole-app stack usage
plug the data into different visualization format. dot's PNG/SVG output is pretty cluttered and hard to read. using something interactive that limits the number of nodes that are displayed at once (e.g. only show a center node and its immediate neighbors) would make the data easier to digest.
we can probably just serialize a petgraph data structure into JSON to begin with. the node "weight" struct should contain at least this information:
structNode{cumulative_stack_usage:Option<u64>,kind:NodeKind,local_stack_usage:Option<u64>,unmangled_name:String,}enumNodeKind{// matches to a symbol / routine in machine codeConcrete,// "fictious" node that represents trait object dynamic dispatchDynamicDispatch{signature:String},// "fictious" node that represents function pointer callsFunctionPointer{signature:String},}
The text was updated successfully, but these errors were encountered:
Being able to output JSON, instead of a
.dot
file, has a few uses:defmt::info
-ing a recursive struct requires recursion?dot
's PNG/SVG output is pretty cluttered and hard to read. using something interactive that limits the number of nodes that are displayed at once (e.g. only show a center node and its immediate neighbors) would make the data easier to digest.we can probably just serialize a
petgraph
data structure into JSON to begin with. the node "weight" struct should contain at least this information:The text was updated successfully, but these errors were encountered: