,
8 tweets,
5 min read
Read on Twitter
🚀 Excited to announce the second release (v0.1.1) of `cargo-call-stack`!
crates.io/crates/cargo-c…
`cargo-call-stack` is a static, whole program stack analysis tool, and in this second release it went from "It works ... sometimes" to "this is awesome!"
Here's what new:
1/8
crates.io/crates/cargo-c…
`cargo-call-stack` is a static, whole program stack analysis tool, and in this second release it went from "It works ... sometimes" to "this is awesome!"
Here's what new:
1/8
Less cluttered graphs!
The hash suffixes (e.g. ::h1337dead10cc4242) are not shown on symbols that are unambiguous. Plus only a single edge is drawn between two nodes regardless of the number times one calls the other.
Here's an example.
2/8
The hash suffixes (e.g. ::h1337dead10cc4242) are not shown on symbols that are unambiguous. Plus only a single edge is drawn between two nodes regardless of the number times one calls the other.
Here's an example.
2/8
Filters!
Interested in the stack usage of only a certain function? Specify it as the _start point_ and the tool will display only the call graph that starts from that node
Example: same program as before but this time `main` was chosen as the start point
3/8
Interested in the stack usage of only a certain function? Specify it as the _start point_ and the tool will display only the call graph that starts from that node
Example: same program as before but this time `main` was chosen as the start point
3/8
Cycles? No problem
The tool will analyze call graphs that contain cycles (i.e. recursion) instead of giving up. It may not always be possible to upper bound the stack usage though!
Here's an example where an upper bound can be computed
4/8
The tool will analyze call graphs that contain cycles (i.e. recursion) instead of giving up. It may not always be possible to upper bound the stack usage though!
Here's an example where an upper bound can be computed
4/8
`dyn`amic dispatch
The tool will attempt to reason about dynamic dispatch (trait objects). It works! ... kinda ... in some cases, but you don't need a custom compiler (just nightly)
Here's an OK example. `i1 ({}*)` means some `fn(&self) -> bool` trait method.
5/8
The tool will attempt to reason about dynamic dispatch (trait objects). It works! ... kinda ... in some cases, but you don't need a custom compiler (just nightly)
Here's an OK example. `i1 ({}*)` means some `fn(&self) -> bool` trait method.
5/8
Fun with pointers
The tool will also try to deal with calls via function pointers. Again, it works OK in some cases and in some cases it will be plain wrong. Best to stick to direct function calls!
Here's an OK example. `i1 ()*` means `fn() -> bool`.
6/8
The tool will also try to deal with calls via function pointers. Again, it works OK in some cases and in some cases it will be plain wrong. Best to stick to direct function calls!
Here's an OK example. `i1 ()*` means `fn() -> bool`.
6/8
Hello world?
I have fixed enough bugs that the tool can now analyze a complex program like "Hello, world!". Its call graph is certainly way more complex than of any of the embedded Rust program I have written!
Here's the (huge) "hello" call graph: japaric.github.io/cargo-call-sta…
7/8
I have fixed enough bugs that the tool can now analyze a complex program like "Hello, world!". Its call graph is certainly way more complex than of any of the embedded Rust program I have written!
Here's the (huge) "hello" call graph: japaric.github.io/cargo-call-sta…
7/8
Bonus graph
The other day I posted the source code of an embedded CoAP server and said that the program contained zero panicking branches when fully optimized
This time I have proof! Here's the call graph of that program: japaric.github.io/cargo-call-sta…
8/8
The other day I posted the source code of an embedded CoAP server and said that the program contained zero panicking branches when fully optimized
This time I have proof! Here's the call graph of that program: japaric.github.io/cargo-call-sta…
8/8
