[LMH] Diagnostic output

[Nyef]

On Sat, 13 Sep 2003, James A. Crippen wrote:

> 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.

Mmm... That sounds much better. Now we just have to figure out how to 
implement it.

> > 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.

Actually, I was thinking that the separate utility would involve dumpq.c, 
dumpraw.c, parts of memory.c, sxhash_test.c, and some glue logic. You 
wouldn't need the function call logic again because it's not emulation, 
but you'd need the memory logic to interpret the DPMT.

> 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.

Well, at this point the system is completely deterministic, so we may as 
well make it configurable. A max-stack-frame-dump parameter or something.
If we don't get enough information from the default we can up the number 
of frames and try again.

The easiest way to implement this is probably an atexit() hook. That would 
save running through the system looking for all the calls to exit().

> 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.

Hell, I could put single-step in now. It's just that it would suck trying 
to single-step through the several hundred thousand instructions we run 
through at this point.

> 'james

---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@softhome.net