remix logo

Hacker Remix

Show HN: CodeTracer – A time-traveling debugger implemented in Nim and Rust

329 points by alehander42 3 days ago | 52 comments

Hey!

We are presenting CodeTracer - a user-friendly time-traveling debugger designed to support a wide range of programming languages:

https://github.com/metacraft-labs/codetracer?tab=readme-ov-f...

CodeTracer records the execution of a program into a sharable self-contained trace file. You can load the produced trace files in a GUI environment that allows you to move forward and backward through the execution and to examine the history of all memory locations. They say a picture is worth a thousand words — well, a video is even better! Watch the demo below to see CodeTracer in action:

https://www.youtube.com/watch?v=xZsJ55JVqmU

The initial release is limited to the Noir programming language, but CodeTracer uses an open format for its trace files and we've started community-driven projects which aim to add support for Ruby and Python.

We are also developing an alternative back-end, capable of working with RR recordings, which will make CodeTracer suitable for debugging large-scale programs in a variety of system programming languages such as C/C++, Rust, Nim, D, Zig, Go, Fortran and FreePascal.

JoeAltmaier 3 days ago

Neat!

Years and years ago I had the opportunity to give Intel processor designers (the time of the 386!) requests for features.

I requested a system tick timer for stamping logs (they did that), bus mask and value registers that triggered a debug interrupt on a match (they did that).

And a jump source history. Maybe 10 jumps back. So on a breakpoint you could figure out how you got there. A time travelling debug feature.

At this point Intel sold an expensive debug probe for recording the bus, you plugged this insane cable into the processor socket and it actually executed in their external hardware, recording every instruction.

My jmp history would have replaced much of that, obviating it's need for the vast majority of users.

Ah well, it didn't happen. So now we all rebuild code 'debug' so we can add tracing and tracking, disrupting the execution path, changing timing and code size and on and on.

I always regretted not getting that.

__init 3 days ago

Intel x86 cores have had Last Branch Records (LBRs) and Branch Trace Store (BTS) since at least Merom in 2006 [1][2]. Nowadays, there's Processor Trace (PT) or Precise Event-Based Sampling (PEBS) which can provide even more information. PT in particular is almost purpose-built to enable this kind of trace reconstruction.

[1] https://stackoverflow.com/questions/14670586/what-is-the-ove...

[2] The MSRs for LBRs (MSR_LASTBRANCH_*_{TO,FROM}_IP) and BTS (IA32_DS_AREA) are described in Volume 4, Section 2.2 of the SDM: "MSRS IN THE INTEL® CORE™ 2 PROCESSOR FAMILY". Core 2 was launched in 2006.

Veserv 3 days ago

Those are only sufficient to produce a execution trace rather than a full data trace which is needed for time-travel debugging.

Though they are sufficient to do what the person you responded to asked for which is just execution trace.

phire 2 days ago

I'm not entirely surprised, adding 40 bytes of SRAM to the 386 for a debug-only feature would have been hard to justify.

cxie 3 days ago

The Noir support makes sense given its use in ZK proofs where execution tracing is particularly valuable, but I'm really looking forward to the Python and Ruby implementations. Those languages' dynamic nature makes bugs particularly elusive sometimes.

Has anyone here tried using this with Noir yet? I'm curious about the performance overhead of the tracing mechanism, especially for longer-running programs. Also wondering if there are plans to support JavaScript/TypeScript for web development use cases.

cxie 3 days ago

The planned RR recordings integration is what I'm most excited about though. Having this capability for systems languages like Rust and C++ would be transformative for complex debugging scenarios where you're often forced to restart debugging sessions from scratch after stepping past a crucial point.

alehander42 3 days ago

the support for system languages (the rr integration "backend") is currently closed source.

It's not ready yet, and it might be proprietary: it would be great if we can open source it, if we find a sustainable business model for that

Apofis 3 days ago

This happens all the time and is super irksome. Being able to step backwards as well as forwards is super cool. Also, being able to do that with a loop using a slider is cool.

cxie 3 days ago

I need a VSCode extension for this. But alas, it's just sitting in their roadmap... Typical. Guess I'll have to roll up my sleeves and build one myself. Not like I have enough on my plate already. At least their trace files are in an open format, so it shouldn't be impossible to hook into the VS Code debugging API.

alehander42 3 days ago

We'd love additional contributors! We also have some more detailed plans for such an extension. If you're interested in chatting about it, you can join our discord[1] (or we can expand here/in a github issue as well)

1: https://discord.com/invite/aH5WTMnKHT

dloss 3 days ago

Noir is a Domain Specific Language for SNARK proving systems. https://noir-lang.org/

01HNNWZ0MV43FF 3 days ago

I see, I see. And what is a SNARK proving system?

michaelsbradley 3 days ago

This paper is a great resource if you're unfamiliar with zk-SNARK and how it works:

Why and How zk-SNARK Works (2019)

https://arxiv.org/abs/1906.07221

conradludgate 3 days ago

"Succinct Non-interactive Arguments of Knowledge", it's a system for zero-knowledge proofs, which allow proving a fact of some kind without disclosing the inputs

slifin 3 days ago

If you are using Clojure or ClojureScript check out FlowStorm:

https://www.flow-storm.org/

alehander42 3 days ago

Very impressive! Lisp people are always good at tooling.