From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,91c5b958fecf5eff X-Google-Attributes: gid103376,public From: Corey Minyard Subject: Re: GNAT exception traceback Date: 1997/06/16 Message-ID: #1/1 X-Deja-AN: 248738055 Sender: minyard@wf-rch References: <339EFAE3.26C@ccis.adisys.com.au> <33A22F37.41CBA26B@erols.com> Organization: Wonderforce Research Newsgroups: comp.lang.ada Date: 1997-06-16T00:00:00+00:00 List-Id: dewar@merv.cs.nyu.edu (Robert Dewar) writes: > > Aaron says > > < 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