[Nickle] trace command omits invariant functions

[Carl Worth]

I was having a rather difficult time interpreting the output of the
trace command.

A minor part of the problem was the program text intermingled with the
stack data. I don't think it's necessarily a bad idea to have the
program text in the trace. But I think the current indentation is
rather confusing:

function1 ()
	text from function2 appears indented under function1 (!)
function2 ()

I don't see an easy way to fix this, (since the trace is already
ordered consistently -- I just have a hard time avoiding the natural
interpretation of the indentation). Maybe just using output in the
style of gdb's where" command is the right approach. Of course, that
would also make the absence of a "list" command much more
noticeable. Also, line numbers would be a nice addition too.

Well, that's mostly whining on my part, and things I could probably
implement myself without too much effort.

A bigger problem is that some function calls are entirely missing from
the stack trace. For example:

	> exception ex();
	> void a() { raise ex(); }
	> void b() { a(); }
	> void c() { b(); }
	> void d() { c(); }
	> d();
	Unhandled exception "ex" at <stdin>:56
	- trace
	    raise ex ();
	a ()
	    d ();
	- 

I assume a compiler optimization has hidden the intermediate calls;
adding some variability makes the missing functions appear again:

	> exception ex();
	> int a() { raise ex(); }
	> int b() { return a() + 1; }
	> int c() { return b() + 1; }
	> int d() { return c() + 1; }
	> d();
	Unhandled exception "ex" at <stdin>:64
	- trace
	    raise ex ();
	a ()
	    return a () + 1;
	b ()
	    return b () + 1;
	c ()
	    return c () + 1;
	d ()
	    d ();
	- 

I assume the information I want may be long gone by the time the
debugger gets involved. Would it be difficult to hold onto enough so
that the debugger can always print a complete stack trace?

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                      cworth@isi.edu