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=0.6 required=5.0 tests=BAYES_05,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,8de5e9f508817948
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-10-27 03:19:45 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!usenet
From: selig.ted@mail.ndhm.gtegsc.com (Selig Ted)
Newsgroups: comp.lang.ada
Subject: Re: Verdix Exception Traceback history
Date: 21 Oct 1994 13:57:25 GMT
Organization: GTE Federal Systems Division
Sender: -Not-Authenticated-[6170]
Message-ID: <388hc5$lbv@europa.eng.gtefsd.com>
References: <2EA6BEBD@SMTPGATE2.STRATCOM.AF.MIL>
NNTP-Posting-Host: rocky.tntn.gtegsc.com
X-Posted-From: InterNews 1.0.1b19@155.95.19.48
Xdisclaimer: No attempt was made to authenticate the sender's name.
Date: 1994-10-21T13:57:25+00:00
List-Id: <comp.lang.ada>


> > >My company is currently evaluating the Verdix compile
> > >on Sun platform.  One problem we have run into is
> > >that when an exception is raised the only traceback
> > >history that is printed is
> > >
> > >  Main Program Abandon Exception ________
> > >
> > >Other compilers I have used provided a text description
> > >of all the subprograms and line numbers the exception
> > >was propergated thru.
> > >
> > >How do I get the Verdix compiler to do this?
> > >
> > >
> > >Walt Barnes  Software Engineer
> >
> > ...
> > ...
> >
> > A SECOND SOLUTION:
> >
> > The call stack can be viewed using the core dump file. The
> > Verdix/Rational Ada debugger version I am using (version 1.1) does not
> > work with core dumps (I hear that future versions will/do).  Instead
> > the dbx tool can be used to view the Ada call stack. To use dbx with a
> > core file follow the steps below.
> >
...
> 
> Am I missing something here?  If re-running the program is an option, you
> don't need a core dump.  Just run the program under a.db until you get the
> exception, and use the "cs" subcommand to print out the call stack.
> 

Your idea works well when the extra memory and processing required by
the debugger is acceptable.

We do not perform System Test while executing in the debugger and we do
not deliver our product with the ada debugger.