Trying to get a NN code going
Richard A. O'Keefe
ok@atlas.otago.ac.nz
Wed, 3 Mar 1999 12:34:47 +1300 (NZDT)
> What I *do* expect from a Pascal or Ada compiler is that it will
> tell me not just where the 'index out of range' was detected, but
> WHERE IT CAME FROM, e.g. a backtrace of some kind.
Ah, I see the confusion. You say you expect such things from the
compiler, where I would expect such things from the compiled program
or from the run time system. A matter of terminology perhaps.
Let me rephrase what I wrote:
What I do expect from any language compiler is that it
will bring it about that a run time error will result
in adequate information about the location of the error.
On a UNIX system, it is the *compiler's* responsiblity to put debugging
information in the object files (as described in the DWARF specification,
if one's using ELF object format). The error report and backtrace will
_happen_ at run time, but they will only happen if the _compiler_ does
something to _make_ them happen.
In a computer language processing system that does not rely on native
object files, the run time system might have a larger share of the
responsibility, but Clean on a SPARC is not such a system.
There's an old technique which can provide useful information even in
the presence of tail recursion and other optimisations. Keep a circular
buffer of procedure identifications (such an identification might be a
pointer to a read-only record containing a file name and line number
and possibly a function name). At the entry point of each procedure,
if this procedure identification is not the last entry in
the circular buffer (or possibly even "not among the last
N entries") then push it.
When the program gets a run time error, print the buffer. This isn't
a backtrace, but it's a useful approximation of one, and it involves
absolutely no dependence on the method used to implement procedure calls.