Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON output + accompanying library #44

Open
japaric opened this issue Sep 17, 2021 · 0 comments
Open

JSON output + accompanying library #44

japaric opened this issue Sep 17, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@japaric
Copy link
Owner

japaric commented Sep 17, 2021

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:

struct Node {
   cumulative_stack_usage: Option<u64>,
   kind: NodeKind,
   local_stack_usage: Option<u64>,
   unmangled_name: String,
}

enum NodeKind {
    // matches to a symbol / routine in machine code
    Concrete,

    // "fictious" node that represents trait object dynamic dispatch
    DynamicDispatch { signature: String },

    // "fictious" node that represents function pointer calls
    FunctionPointer { signature: String },
}
@japaric japaric added the enhancement New feature or request label Sep 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant