This is something that does not require a debugger perse. this is something that can be implemented by a "smart" log. beside the log entry there might be a button to see the trace + state at those points. could even allow log() to have an option for this.

▲ nananana9 5 days ago | parent [-]

But you have to

  1. stop the program
  2. edit it to add the new log
  3. rebuild the program
  4. run it
  5. get the program to the same state to trigger the log

3. can take quite a while on some projects, and 5. can take quite a while too for long-running programs.

And then you see the result of what you printed, figure out you need something else as well, and repeat. Instead you can just trigger a breakpoint and inspect the entire program's state.

▲

pavon 4 days ago | parent | next [-]

For 3, printf debugging is often faster for me because it only requires an incremental rebuild. Whereas with gdb, it is very likely that the release build doesn't show me what I want to see, so I need to do a full debug build from scratch which takes much longer, and sometimes no longer replicates the bug.

	▲	o11c 4 days ago \| parent [-]
		That hints that you might be doing one of three things wrong. Either: * You're using to doing things the Windows way, where debug and release are completely different profiles rather than orthogonal flags. Or, * You're compiling using Clang, which gives up and limits debuggability to simple backtraces when optimization is on. Or, * Your project is hopelessly bloated and linking with debuginfo is slow, but you haven't figured out external debuginfo. With GCC, `-g -O2` is a reasonable thing to use for all builds and provides a pretty good debugging experience with only minor competence required to find equivalences for any <optimized out>s.

▲

ranger_danger 4 days ago | parent | prev [-]

https://rr-project.org/