🚀 go-pugleaf

Something that bothers me often when debugging code with a
source debugger is inadvertantly stepping past the piece of
code I was interested in. I want a debugger that can run my
code backwards as well as forwards while honouring breakpoints
and does all the things you usually get while running forwards.
(step to previous line, step to last line of code executed, etc.)

	I think Borland sells a debugger kind of like this but
it wasn't much chop last time I used it, it refused to step back
past a function return.

	This is not difficult to do in principle. I wrote an
interpreter for a subset of c that was vaguely like those integrated
MS-DOG environments. It sat inside a parsing editor and could run
code interactively, showing variable values and it didn't make a big
fuss about running code backwards, everything you could do forwards
you could also do backwards. It's easy to guess how this was done.

	Now you can obviously make a compiler generate code that
can be run in both directions equally easily. You do have to save
a heap of stuff on a stack, but that's not a big problem memorywise.
You can re-cycle this memory when you hit the end of it. This just
means you can't step backwards indefinitely. And it slows things
down (but you don't really care about this much when you're debugging.)

Library functions would also have to save enough info to be run in
reverse for this to work properly. You'd also need wrappers around
system calls that can also reverse their effects when running
backwards. So you'd need a special debugging library.

	When I was writing this thing a few people said things like
"I wish dbx/ups could do that too." so my questions are:

	1) Does anybody else think this would be useful enough to do.
	2) How difficult would it be to modify the back end of a real
	compiler (gcc?) to do this?
	3) Would there be any way to do this without modifying the
	behaviour of compiled code *at* *all*? (I realy hate systems
	that change the behaviour of your code when you compile with
	debugging or when you run it under a debbugger.)

	Such a compiler would generate huge and slow code when you
compiled with this option so you wouldn't want to compile everything
with debugging on like sensible people do now.

Would a suitable back-end and library be worth doing?

Another random question: Is there any sensible way at the moment to
debug shell scripts using bash and gdb? (I'd like to debug shell
scripts like they were any other high level language.)

Regards,
	Matthew.