Please show me this being used to debug a real program. Toy examples that don’t do any real work isn’t interesting. My confidence that this work for an actual program is approximately zero percent.
Cool, reminds me somewhat of Glamorous Toolkit [1], another project I just found out about. Excited to give it a try, I love these sort of "explain a program as it's running" type tools.
From a debugger's point of view, Rust is just another native code language. DWARF tells you how to get stacks, find variables, and interpret chunks of memory as data structures. Anyone trying to pitch you a debugger specifically for Rust is trying to ride a hype wave or just plain bamboozle you.
While that’s sort of true, there’s a lot of language specific things that go into making the UX of a debugger pleasant (think container abstractions, coroutines, vtables and interfaces). Specifically async rust and Tokio gets pretty interesting for a debugger to deal with.
Also, there’s usually some language (and compiler) specific garbage that makes the dwarf hard to use and requires special treatment.
Sure, I agree, but in my experience, probe-rs for example has much better ability to step and identifies the variables much better than GDB did. Not sure if it's how it handles the name mangling or what, but GDB couldn't interpret a lot of context.
Where do you see source instrumentation? I see Rust-specific details so for sure it's language-specific, but I didn't see any mention of altering the source code.
I didn't look at it very closely but it seems like you need to add fire::dbg! macros to your code if you want anything beyond function parameters/return values.
Oh. When I read the section on instrumenting function returns, I thought they were going for something more general, since they talk about analyzing assembly. Now I see they're looking at individual Box and Rc instances and have special cases for stdlib data structures. Async support is also a to-do item.
I can't see this approach working for very long. Tracing at the binary level, whether you do it as RR does with performance counting or whether you do it via instrumentation like Undo and iDNA, works for the general case because it records execution at the lowest level available to a process and therefore captures everything, without special cases.
If these guys want to make a fancy time travel debugger data explorer, that's great. They could in principle make one on top of existing tracing technology without having to simultaneously reinvent both the debugger core and the GUI.
Wow. It is not even a proper time travel debugger. I just assumed they were ingesting a proper time travel debugger log and driving a proper replay engine and just wrote a bad integrated trace viewer on top. That would at least be excusable. This is just inane.
The "time travel debugger" solution they use automatically sets numerous breakpoints and then records a tiny, useless fraction of the information needed to actually recreate past state, but is almost certainly slower than any actual, fully-functional time travel debugger by multiple orders of magnitude. That was the same technique used by the built-in gdb "reverse debugging" which, at least historically, resulted in 1,000x-10,000x (yes, really) slowdown compared to modern techniques which are on the order of 2x-10x. And to at least give gdb some credit, gdb reverse debugging was at least a complete time travel debugger since it recorded everything; it was just unusably slow. That is more than can be said about whatever this is. They would be significantly better off in both functionality and performance wrapping literally any other actual time travel debugger solution.
Then we add on their awful, bespoke trace viewer. I originally just chalked it up to them being unaware of standard practices since most people are unfamiliar with time travel debugging and the associated tooling and they just wanted to show off what they did with some bluster. That is excusable, if somewhat unfortunate. But this is the metaphorical equivalent of claiming you have solved the problem of inserting screws because you invented the hammer which is much better at hammering in screws than a brick.
Their marketing statements are unacceptable misrepresentations of their capabilities with respect to commonly-accepted meanings.
It is utterly baffling that this is more popular than the recent UndoDB thread [1]. They have a real time travel debugger and have been doing it for like 15-20 years. They are actual veterans doing quality engineering.
That's the culture that's emerged in tech over the past few years: a rejection of technical rigor and an abuse of language to ape, poorly, the cachet of past accomplishments. This thing is a "time travel debugger" (it isn't). A program to bundle typescript into an executable is called a "compiler". They use cool-sounding words without the substance.
This is just a trace viewer. Except the trace visualization is vastly less dense than any standard trace viewer and seems to provide no meaningful execution time information.
I am not sure if trace visualizers were invented 20 years ago for the original time travel debuggers, but they have certainly been used for time travel debugging visualization since at least 20 years ago.
It's definitely a little more than just a trace viewer.
As the page reads, it is a time traveling debugger. You can jump back and forth between different snapshots of time during the execution of your program. It's neat because for compiled languages like rust doing something like this is more advanced.
It's both. It is a trace viewer, but they instrument native code to emit logs of its operation, e.g. calls and returns, similar to what the recent non-performance-counter rr branch does. Except for some reason it's coupled to a specific GUI and a specific language instead of being a general purpose tool like RR is.
The tech industry is getting stupider and hype-ier as it implodes.
They're just trying to offer an easy way to try things out and unsafe code from Firefox would be insanely harmful for their brand. Of course, if you take a moment to merely download the bash script and inspect it. It's truly not dissimilar from downloading a repository from GitHub and building it. In general, certainly, yes, you don't want to run arbitrary programs.
Depending on where your "Internet" boundary starts, you can clone the repo and run its install.sh although I think it's for really lazy people since it just downloads the GitHub release artifact anyway https://github.com/SeaQL/FireDBG.for.Rust/blob/1.81.0/instal...
I'm a little with you that it is sus that they don't seem to have any .ts nor package.json file in that repo which would allow one to (a) see what the extension does (b) build the .vsix themselves
Rust really embodies this imo. I think it will be a few more years, but we're going to be seeing a lot more Rust -- and for good reason.
anyone know the tool name??? I know it exist but forget it while ago
https://learn.microsoft.com/en-us/sql/relational-databases/p...
1. https://gtoolkit.com/
Also, there’s usually some language (and compiler) specific garbage that makes the dwarf hard to use and requires special treatment.
Is it like just a trace viewer fed data by debugger-style mechanisms?
https://firedbg.sea-ql.org/blog/2023-12-11-architecture-of-f...
I can't see this approach working for very long. Tracing at the binary level, whether you do it as RR does with performance counting or whether you do it via instrumentation like Undo and iDNA, works for the general case because it records execution at the lowest level available to a process and therefore captures everything, without special cases.
If these guys want to make a fancy time travel debugger data explorer, that's great. They could in principle make one on top of existing tracing technology without having to simultaneously reinvent both the debugger core and the GUI.
The "time travel debugger" solution they use automatically sets numerous breakpoints and then records a tiny, useless fraction of the information needed to actually recreate past state, but is almost certainly slower than any actual, fully-functional time travel debugger by multiple orders of magnitude. That was the same technique used by the built-in gdb "reverse debugging" which, at least historically, resulted in 1,000x-10,000x (yes, really) slowdown compared to modern techniques which are on the order of 2x-10x. And to at least give gdb some credit, gdb reverse debugging was at least a complete time travel debugger since it recorded everything; it was just unusably slow. That is more than can be said about whatever this is. They would be significantly better off in both functionality and performance wrapping literally any other actual time travel debugger solution.
Then we add on their awful, bespoke trace viewer. I originally just chalked it up to them being unaware of standard practices since most people are unfamiliar with time travel debugging and the associated tooling and they just wanted to show off what they did with some bluster. That is excusable, if somewhat unfortunate. But this is the metaphorical equivalent of claiming you have solved the problem of inserting screws because you invented the hammer which is much better at hammering in screws than a brick.
Their marketing statements are unacceptable misrepresentations of their capabilities with respect to commonly-accepted meanings.
It is utterly baffling that this is more popular than the recent UndoDB thread [1]. They have a real time travel debugger and have been doing it for like 15-20 years. They are actual veterans doing quality engineering.
[1] https://news.ycombinator.com/item?id=44076300
Compare to chrome://tracing
https://www.chromium.org/developers/how-tos/trace-event-prof...
I am not sure if trace visualizers were invented 20 years ago for the original time travel debuggers, but they have certainly been used for time travel debugging visualization since at least 20 years ago.
As the page reads, it is a time traveling debugger. You can jump back and forth between different snapshots of time during the execution of your program. It's neat because for compiled languages like rust doing something like this is more advanced.
You click a point in the trace, you jump to that point in time. That has been the standard integration for decades.
The tech industry is getting stupider and hype-ier as it implodes.
- Bash script from Internet requiring sudo, no way
- VSCode plugin? I don't use VSCode. I'm not switching from Zed (literally built in Rust for Rust development)
Help me out, what can I do to try this?
I don't see that VSCode is required, they have a section dedicated to CLI usage https://github.com/SeaQL/FireDBG.for.Rust#firedbg-command-li... and even the "firedbg open" seems to just be a convenience method for file globbing https://github.com/SeaQL/FireDBG.for.Rust/blob/1.81.0/comman...
I'm a little with you that it is sus that they don't seem to have any .ts nor package.json file in that repo which would allow one to (a) see what the extension does (b) build the .vsix themselves
On mobile (Firefox on iOS) why does this site keep putting animations in my face?