I just found it, great tool, have been working on the same concept but for Clojure!

[jpmonettas]

For the past 5 years I've been working on a very similar FOSS project https://www.flow-storm.org/ but for Clojure!
Open to meet up if you are interested, maybe our projects can inspire each other.
I've met Bill Lewis (old omniscient debugger) and Mark Williamson (from undo.io) also, maybe we should start a time-travelers group!

[tyt2y3]

Thank you. Let's connect via email I guess?
kudos to the great work, FlowStorm is a way more mature project than FireDBG!
I partially regretted that I started with Rust, because having to cope with a changing ABI plus different ISAs is too much work that is unrelated to making a visual debugger.

I wonder what's your idea / comment on call tree visualization?

[jpmonettas]

Sure!

I partially regretted that I started with Rust

I can imagine Rust being much harder for this kind of things than a functional lang on the JVM, although I haven't tried yet (I willl) but it seems you got it pretty far!

I wonder what's your idea / comment on call tree visualization?

So, FlowStorm is more about "ergonomically" recording the activities (every expression, fn call, fn return, etc) happening on every thread as the application runs into timelines (arrays of events). This is easy in Clojure because almost everything is immutable, so recording is mostly about leaking pointers. The idea is to "reify execution", so to have execution as data. After that, it provides a GUI to visualize that data in different ways, like a stepper, a call tree, etc.
My current view is that once you have "execution as data", you then have a data analysis problem, so you can create as many tools as you can imagine to extract insights from the execution, that hopefully helps you to understand it at different levels. Like a stepper for fine grained, call tree for medium level, and custom visualizations for very high level. If you are interested in what I mean by this different levels here is a recent demo of me working with the internals of a real compiler written in Clojrue, and then trying to understand its execution.

Because of Clojure's interactivity, you can also access that data programmatically, so you can also write code to figure things out from the recordings if the tools provided by the GUI are not enough.