This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Omniscient Debugging for C...

Bil Lewis wrote:

> It could be written in C/C++/etc. also. This would involve
> augmenting the compiler to produce "tracing code" at all
> assignments and function calls.
> I don't know GCC and it's highly unlikely that I shall ever
> learn it alone.
> But if someone who did know it was interested in doing something
> truly extraodinary...

I've used systems like this before, but only in the form of in-circuit
emulator with bondout processors (ie with massive hardware assist).
However, it was astoundingly effective, and I've always wanted to try and
do something like on the PC :-) However, I have to wonder how it can work
with the compiler doing the annotation - what about library calls (which
won't be annotated). How will it cope with these holes in its data?

Just to throw it out there - have you considered using something like
valgrind to do the instrumentation dynamically? When I last considered
trying to do something like this, that was the approach I was studying, and
valgrind has since added very nice support for pluggable instrumentation
skins that would have made it a lot easier. It has the immense advantage of
working on ordinary executables (of course, to understand the results you
need symbols, but ordinary debug builds (or even optimized with symbols)
work, and it works nicely on apps linked to libs that don't have symbols -
you just can't study the data as well, but none of it is missing)

It wouldn't be the that much different from the existing memcheck skin in
invasiveness; the storage requirements would be higher, and it would have
to support some form of circular buffering instead of keeping a 'current'
image, but it wouldn't really need much from the instrumentation that would
be different from what's available...

Actually, the part that basically defeated me before was the more
traditional 'debugger' part of it - how to I read the debug symbols and
interpret the data well enough to be a useful real tool. The only UI I had
in mind that I thought I could pull off was that of being able to
single-step - but both forward and backward. Go up the stacktrace, and 'run
it again' from there. Etc. 

Thus, I'd have the same basic UI as a traditional debugger, but the ability
to go back in time instead of just forward (albiet unable to change things
until you were caught up within the present block (as bounded by syscalls,
since I can't account for the side effects of those - anything that was
local to the process it's possible to undo since I have the memory change
log). To dodge the symbol reading and UI for this, I was planning to try it
as a GDB remote stub that fed it "memory images" reconstructed at each
point in time. That seemed doable, but it only partially shows off what the
systm could do :-) Mostly I gave it up back then because (at that time) I
was considering it as a class project, and I came to my senses instead of
committing suicide like that :-)

So, now you know the evil plan I had in mind, and I guess you can tell I'm
at least 'strongly interested'.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]