Reverse Execution in GDB 7 is imminent

http://www.gnu.org/software/gdb/news/reversible.html

by grogers • 17 years ago

124 40 17 years ago

gcv• 17 years ago

Very slick. I wonder if this upcoming release adds proper support for C++ templates. As is, I don't know of anything other than Visual Studio which makes debugging STL or Boost-heavy C++ code a reasonable task.

grogers• 17 years ago

For that you can check out Project Archer:

http://sourceware.org/gdb/wiki/ProjectArcher

yan4• 17 years ago

This has great potential for security researchers.

ciupicri• 17 years ago

Can you elaborate on this? Are talking about the fact that some silly bugs like buffer overflows will be fixed more easily?

yan4• 17 years ago

I was approaching this from the opposite direction; writing and debugging shellcode will be more pleasant. Or rather, when I have spent time writing shell code, I wished for such a feature.

ars2• 17 years ago

Can this reverse through a seg fault?

ori_b2• 17 years ago

Why wouldn't it be able to? A segfault is just a signal like any other.

ars2• 17 years ago

I thought it couldn't be caught, but I checked the docs, and it seems it can.

Hmm, maybe I should put that in all my programs - then I won't ever have bugs from segfaults.

yan4• 17 years ago

Because the state of a process is undefined after a seg fault.

muon• 17 years ago

Till now, I believed this was impossible to do.

adamt• 17 years ago

It's been possible for quite some time. Someone I vaguely know set up a startup back in 2006 looking to do just this: http://undo-software.com/

zandorg• 17 years ago

In 2006, I wanted to see if it was possible, so I wrote (in C++) a virtual CPU with 2 registers (A and Program Counter) and input (In/Out ports) and the basic idea was it'd log everything (per cycle) in a reversable form.

Unfortunately I was too lazy to finish it, but I think it would have worked. It was just a proof of concept.

woadwarrior01• 17 years ago

Ocaml's debugger has a similar time travelling feature.

huhtenberg2• 17 years ago

You believe incorrectly. Borland C++ IDE supported reverse execution back in early 90s.

msnyder6• 17 years ago

Yes, but AFAIK that was only for a very limited duration trace buffer. You're right, it is basically the same thing, but gdb can now do it for millions of instructions.

mahmud2• 17 years ago

As long as you run it forward once, you should be able to do reverse execution. What you consider "impossible" is taking a binary and executing it from its last instruction up to the first: that would be impossible, or at least ill specified, because a program could have many exit points, but only one entry point.

kijiki• 17 years ago

VMware Workstation can do this for entire VMs. They call it "replay" IIRC.

bigmac• 17 years ago

IIRC, The gdb team was previously talking implementing this by forking after every instruction. Does anyone know if the current functionality is being built on that model?

I guess the advantage of doing it that way is that the majority of the memory pages can be shared if the OS uses a copy-on-write virtual memory system.

This:

Breakpoints and watchpoints will work in reverse -- allowing you for instance to proceed directly to the previous point at which a variable was modified.

is going to absolutely killer functionality for reverse engineers.

msnyder6• 17 years ago

No, it doesn't fork at all, it simply records the values of registers and memory that will be modified by each instruction, so that they can be restored later.

Aegean• 17 years ago

Finally!

nathanb• 17 years ago

I assume that this will only work if you've executed the program inside of GDB, not if you load a core file that was dumped earlier outside of GDB?

varjag• 17 years ago

Given that it has to record state changes somehow, that makes sense.

msnyder6• 17 years ago

In fact, gdb can record the state changes and then store them into an "enhanced" core file, which can then later be used to debug the program in reverse.

It's rather like adding a "time" dimension to your core file. ;-)

yan4• 17 years ago

Thinking about it, that would be the ultimate hack. If the core file does indeed have all the regions mapped when the core was dumped, you can theoretically load them as before then back-step each instruction since they are fairly well defined.

The huge issue here is, the most probable reason for segfaulting was an unexpected value coming from the environment and it's impossible to know the environment the process was running in post-mortem.

lallysingh• 17 years ago

Lots of state is lost! Like the prior values of variables.

bokchoi• 17 years ago

Ever since I saw Omniscient Debugger (ODB), I've wanted this feature integrated into my IDE. ODB was interesting but didn't seem to take off. I'm glad GDB is raising the debugger bar.

http://www.lambdacs.com/debugger/

mc• 17 years ago

yawn check out the ODB (for Java) which allows backward and forward debugging.

http://www.lambdacs.com/debugger/

watch the author give a talk at Google: http://video.google.com/videoplay?docid=3897010229726822034

TwoBit• 17 years ago

FWIW, Borland C++ had this on PC back in ~1994. It worked pretty well most of the time.

msnyder6• 17 years ago

I remember that -- but I never knew any details. Do you? Did it have a fixed-size buffer for instruction trace? Did it perform well on reverse step into/over functions? How was the speed performance?

yason• 17 years ago

I've been toying with the idea myself, I even considered writing a Valgrind plugin to keep a record of how values change in register and memory until I got scared enough of the complexity and enormity of the code.

I wonder how much memory will it take to run a "usefully large" program with state recording on? In theory you could compress some memory mutations pretty easily (like bzero()ing something) while other mutations would need more memory (writing single ints to various locations). I bet you could generate some nifty 10GB logs with this thing!

msnyder6• 17 years ago

You're right of course. It consumes tens of bytes of ram per executed instruction. But computers have gigabytes of ram these days, so it all comes down to what you consider a "usefully large" program. Millions of instructions -- no problem. Billions -- can't do that. ;-)

wlievens• 17 years ago

Do they need any substantial changes in DWARF to pull this off?

msnyder6• 17 years ago

No changes in elf or dwarf.

Reverse Execution in GDB 7 is imminent

Related Stories