Re: GNAT exception traceback

[Corey Minyard <minyard@acm.org>]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> 
> Aaron says
> 
> <<It would be an EXTREMELY valuable capability if the
> Ada.Exceptions.Exception_Information function carried with it some
> information about where the exception was originally raised or even
> better a full traceback.
>  
> This may be too much baggage to justify implementation in the compiler
> but nevertheless it would provide a useful capability to a certain group
> of users.>>
> 
> 
> No quarrel with that. At least providing the location where the exception
> was raised is perfectly feasible if you are willing to accept some additional
> space overhead in your program to store the neccessary information, and this
> is something that will get added to GNAT one of these days (so far it is not
> a feature that any of our customers have had at the top of their priority
> lists, so hence it is not at the top of ours).

Well, being a GNAT customer, I'm going to have to raise that to the
top of my priority list :-).

I have sent Robert a patch that does this (although I know he is
probably going to rewrite it to make it right).  You can have the
patch (It also has stuff to modify Linux to use LinuxThreads and build
shared libraries for Linux) at http://www.concentric.net/~Minyard.

> 
> Full tracebacks are another matter. There are serious performance penalities
> in making exception occurrences be of arbitrary length, and also some very
> nasty cases. In particular, if you force allocation of exceptoin occurrences
> on the heap, which obviously is whaat has to be done if the information is
> variable length, then you really have problems with Storage_Error. There is
> also a question of exactly where this information gets released. The reason
> that exception messages can be limited in length by an implementation is
> precisely to avoid this kind of problem (see the AARM for further details).
> 

As much as I dislike this, I have to agree with Robert about the cost.
Tracebacks can be VERY expensive.  I wrote a debugging memory manager
for VxWorks; part of what it did was keep a traceback of every malloc
and free (only 4 levels).  On a Sparc this took over 50% of the CPU
for this function alone!  On a 68K it wasn't too bad, but it was still
significant.  This cost would be paid on EVERY exception, caught or
not, data used or not.

I disagree with Robert on the machine-dependant part.  There is a
machine-independent option.  On every procedure call, right before the
call, GNAT could generate a three-word traceback frame on the stack
with a pointer to a string holding the filename, a line number, and a
pointer to the previous traceback frame.  A task-specific variable
could hold the pointer to the current traceback frame.  Using my patch
to get the current location, it would be easy to walk this back.
However, a rather high cost is paid on every procedure call.
Tracebacks from the field are useful enough, though, that this might
be a good option to have.  Also, the traceback frames could be on a
separate stack that was not destroyed by normal stack operations, so
the traceback could only be extracted when it was needed.

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com