[LMH] Diagnostic output

[James A. Crippen]

Nyef <nyef@softhome.net> writes:

> Well, what I was thinking was that it might be nice to have an
> 'uninteresting function' list, like the error handler system has,
> which just disables diagnostic output while in those functions (but
> not in subfunctions, so we can ignore stuff like dolist when it's
> not inlined by the compiler and other such).

That could get really hairy since we'd start building up a really
large list of functions that we don't want to hear about
normally. This is why I was thinking of having 'categories' of
functions that were uninteresting in related ways. It would obviate
the necessity to specify particular functions.

But then again, if we had a system that was built around specifying
particular functions we could predefine certain categories of
functions and then provide an option to dis/enable those categories
rather than the explicit functions themselves. You grok? Build the
particular system and then provide a generalized interface, but one
that the user can subvert if necessary.

> Another idea would be disabling the whole bit about dumping a full
> FEF when entering it and having a separate utility to dump a FEF
> given its address (or, if we're feeling adventurous, its name). This
> would be kind of inconvenient if it didn't dump the FEF that
> emulation stopped on, though.  Perhaps a 'do-not-dump-fef' list
> would be appropriate?

I don't think a separate utility would be a good idea since it would
replicate much of the existing function call handling. We wouldn't
benefit from having that separated out into its own library,
either. Better to have the control for such information built into the
emulator itself.

> Yet another idea is to replace all the calls to exit(-1) with a call
> to a function that dumps out some of the interpreter state before
> exiting. The context structure, the current function stack, etc.

I honestly think that this should be mandatory. Every crash should die
with a full state output on console. Just like a Linux or WinNT kernel
panic. The only thing to think about is exactly how detailed it should
be. If the function stack should be printed out in its entirety or
just the last few calls, or whatnot.

> My sympathies. I had enough trouble just getting postfix, procmail,
> pine, and fetchmail on speaking terms.

Yark. Ugh. Barf. Et cetera.

> Let's think for a little bit about exactly what sort of debug output
> control we really want before implementing it, though. We both could
> be completely off base about what's really needed, after all...

I feel that *all* of the debug information that currently exists
should be available with some maximum level of debugging enabled. But
normally most of it is uninteresting, so it should be disabled in
ordinary circumstances. A system that retains all existing debugging
info (and even adds some if possible) is necessary, and one that
retains such as well as providing a way to muffle uninteresting parts
of the output in a fully user-configurable manner is I think
sufficient. More than that is extra that can be pasted on top later.

Actually, once we get that level of control implemented it wouldn't be
too terribly difficult to implement some sort of single-stepping
subsequently. But I don't want to delve into that now.

'james

-- 
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W                     Recursion 'R' Us
Anchorage, Alaska, USA, Earth            Y = \f.(\x.f(xx))(\x.f(xx))