Re: GNAT : Exception traceback

Re: GNAT : Exception traceback

[Robert Dewar]

Richard Toy asks

"Does anybody know if it is possible to get a full exception
traceback from code compiled using GNAT 3.01 under Solaris or
WIndows 95."

Yes, the documentatoin (gnatinfo.txt) knows! Everyone using GNAT should
be sure that they have this documentation file (and read it :-)

GNAT exception traceback

[Steve Gibson]

I have a question regarding exception tracing under the GNAT Ada95
compiler.

Running GNAT 3.05 on DOS 6.x and GNAT 3.07 on Solaris 2.5.1. On both
platforms, when an exception is raised and propagated to the top level
procedure ("main") and not caught, the code generated by the GNAT
compiler, correctly, reports "raised ADA.IO_EXCEPTIONS.DEVICE_ERROR" for
instance.
My question is, without running gdb or adding additional exception
handlers, is it possible to generate traceback information to determine
which line of code in which package generated the exception, and if so
how ?

For example:
    CONSTRAINT_ERROR exception raised in package XXX line i
    CONSTRAINT_ERROR exception propagated out of package YYY line j
    CONSTRAINT_ERROR exception propagated out of package Main line k

Thanks for any help.  

-- 
Steve Gibson
ADI Limited, CCIS Systems Group 
Email: gibson@ccis.adisys.com.au
Snail: 22 Stirling Hwy
       Nedlands
       Western Australia
Nbrs : (tel) +61 9 333 8917    (fax) +61 9 333 8889

Re: GNAT exception traceback

[Robert Dewar]

Steve asks

<<My question is, without running gdb or adding additional exception
handlers, is it possible to generate traceback information to determine
which line of code in which package generated the exception, and if so
how ?
 >>


You need to run gdb to get the traceback. This is easy to do, so it is
not clear why you set the precondition of not using it (your question is
a bit like saying: can I use GNAT to compile my Ada program without
using gcc -- the answer in both cases is no!)

Re: GNAT exception traceback

[Robert Dewar]

Huy says

<< 
I'd think dumping a core would be nice; at least you can look at the call
stack. But doing it the C way would be sacrilegious, right?
 >>

No, that's the point, you can't look at the call stack in a core dump, because
by the time you know an exception is unhandled, it's too late, the stack has
been unwound and destroyed. This is something that needs improving in future
versions of GNAT (the SGI version of GNAT using WORKSHOP handles this nicely
right now).

Re: GNAT exception traceback

[Huy Vo]

>> You need to run gdb to get the traceback. This is easy to do, so it is
>> not clear why you set the precondition of not using it (your question
>> is
>> a bit like saying: can I use GNAT to compile my Ada program without
>> using gcc -- the answer in both cases is no!)
>
>I think this feature (traceback without gdb) would be very useful. It would
>allow us to have a trace of errors occurring at our customers' sites without
>reproducing the bug in our environment, which is often impossible.

I'd think dumping a core would be nice; at least you can look at the call
stack. But doing it the C way would be sacrilegious, right?

vo@ctron.com

Re: GNAT exception traceback

[Mats.Weber]

> You need to run gdb to get the traceback. This is easy to do, so it is
> not clear why you set the precondition of not using it (your question
> is
> a bit like saying: can I use GNAT to compile my Ada program without
> using gcc -- the answer in both cases is no!)

I think this feature (traceback without gdb) would be very useful. It would
allow us to have a trace of errors occurring at our customers' sites without
reproducing the bug in our environment, which is often impossible.

Re: GNAT exception traceback

[Aaron Metzger]

Robert Dewar wrote:
> 
> Steve asks
> 
> <<My question is, without running gdb or adding additional exception
> handlers, is it possible to generate traceback information to determine
> which line of code in which package generated the exception, and if so
> how ?
>  >>
> 
> You need to run gdb to get the traceback. This is easy to do, so it is
> not clear why you set the precondition of not using it (your question is
> a bit like saying: can I use GNAT to compile my Ada program without
> using gcc -- the answer in both cases is no!)

I believe that Steve's question does have merit.

I was going to wait until I had studied the implementation of exception
handling in GNAT before posting a similar question but since someone
brought it up here goes ...

We develop applications written in Ada for use in embedded systems.  Due
to limited resources in the embedded target, the production code is
generally delivered with a few judiciously placed exception handlers in
outer scopes to recover the system just in case something slipped
through testing and propogates an unhandled exception.

The systems are first subjected to extreme operating conditions while
many miles away from the software developers and a debugger.  If an
error occurs it is often not repeatable due to the complex environment
that the system is in.

This means that we get just one chance to collect all possible
information about what the software was doing at the point that an
exception was propagated.

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.

------------- 
Aaron Metzger

Re: GNAT exception traceback

[Martin Kristensson]

Steve Gibson wrote:
(snip)
> My question is, without running gdb or adding additional exception
> handlers, is it possible to generate traceback information to determine
> which line of code in which package generated the exception, and if so
> how ?
> 
> For example:
>     CONSTRAINT_ERROR exception raised in package XXX line i
>     CONSTRAINT_ERROR exception propagated out of package YYY line j
>     CONSTRAINT_ERROR exception propagated out of package Main line k
(snip)

Why not simply add an exception handler to each subprogram, which will
store the name of the subprogram (or simply echo the name to the
terminal) and then re-raise the exception.

...
exception
   when others => Trace_Exception(Package_Name, 
                                  Subprogram_Name);
                  raise;
end Subprogram;

The final handler (i.e. the main program) can print/store the name of
the raised exception (using Ada.Exceptions.Name), together with a
message to the user.

If it seems like to much work, use a script to insert the extra lines,
or only add the handler to routines that are "at the start of" the call
chain.

We use this approach at work, since our customers use classified
(military) input files, so we generally can't recreate the error.
The exception trace file provides at least a clue to what went wrong.

/Martin.

Re: GNAT exception traceback

[Robert Dewar]

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

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

Re: GNAT exception traceback

[Robert A Duff]

In article <dewar.866289217@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Full tracebacks are another matter. There are serious performance penalities
>in making exception occurrences be of arbitrary length, and also some very
>nasty cases. ...

How about storing a fixed-length traceback?  Usually the top few stack
frames are enough for debugging.  So you could pick some number, say 40
stack frames, and store that many from the top of the stack.  No need to
use the heap, unless the programmer explicitly copies it to the heap.
Or maybe the top 30 and bottom 10.  Or maybe make it user configurable.

Although Exception_Information returns a String, the traceback data
should be stored internally in a more compact form (a series of return
addresses, or some such), and converted to String when E_I is called.

- Bob

Re: GNAT exception traceback

[Robert Dewar]

Mats says

<<I think this feature (traceback without gdb) would be very useful. It would
allow us to have a trace of errors occurring at our customers' sites without
reproducing the bug in our environment, which is often impossible.>>

When our customers start saying the same thing and putting this at the top
of the list, and are willing to pay the high development cost associated
with this feature (it is a large amount of work, because it is highly
target dependent, and we avoid target dependent stuff where we can to maintain
the easy portability of GNAT), then maybe it will get done.

But I doubt it, the cost/benefit ratio is probably too high for this feature
to see the light of day. 

What is however, much more practical, and which is definitely on the list of
things to do is to have the runtime clearly detect an unhandled exception
with the run time stack intact. That will be implemented as part of our
current work in reimplementing the exception mechanism generally.

Then you can simply dump core at the point where such an error occurs, and
analyze the core dump with gdb later. This gives essentially equivalent
capability with two big advantages:

1) no overhead in the running program to allow for the generation of tracebacks

2) no target dependent work required in the runtime, other than the basic
work to handle exception handling, which is needed in any case.

Robert Dewar
Ada Core Technologies

P.S. the VMS implementation of GNAT *does* provide full tracebacks. That's
because it is part of the VMS ABI. Too bad that all manufacturers do not
pay attention to the exception issue when they specify ABI's. Not only
has Digital always carefully considered these issues, but they have always
had significant Ada input in the design process, so their design for system
ABI level handling of exceptions is nicely consistent with the requirements
in Ada.

Re: GNAT exception traceback

[Robert Dewar]

Steve says

<<Why not simply add an exception handler to each subprogram, which will
store the name of the subprogram (or simply echo the name to the
terminal) and then re-raise the exception.>>


Two things to be aware of with this suggestion.

1. If your compiler uses an approach that costs entry time when an exception
handler is declared, this might cause significant slow down in execution
time. GNAT is currently like this. This approach results in fast exception
propagation but at the cost of slow setup time on handlers. That of course
is the wrong tradeoff (it is a lot of difficult target dependent work to
do the proper zero cost solution, and we are working on that now).

2. If your compiler *does* generate nice trace backs on unhandled exceptions,
then you will undermine it by this approach.

In particular, when we get the feature put in of avoiding destroying the
stack on an unhandled exception, then you will be able to breakpoint on
an unhandled exception and get a nice detailed traceback from GDB (with
all the arguments at each level etc). You will undermine this capability
if you put exception handlers in every procedure.

Note: if your program does not in general use Constraint_Error as a control
flow mechanism, i.e. you do not have any exception handlers for 
Constraint_Error in your program, or when others handlers, then you can
do something quite easily now which may be useful in some cases. Simply
add code at __gnat_raise to check if the exception is constraint error,
and if so, abort. \

Then you will get a core dump which you can examine at leisure using GDB.

Re: GNAT exception traceback

[wiljan]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.866242346@merv>...
> Huy says
> 
> << 
> I'd think dumping a core would be nice; at least you can look at the call
> stack. But doing it the C way would be sacrilegious, right?
>  >>
> 
> No, that's the point, you can't look at the call stack in a core dump,
because
> by the time you know an exception is unhandled, it's too late, the stack
has
> been unwound and destroyed. This is something that needs improving in
future
> versions of GNAT (the SGI version of GNAT using WORKSHOP handles this
nicely
> right now).
Note that this will only allow to get to the exception raised by the main
program.
When exceptions happen in tasks they simply disappear without a message
or anything from the program (at least on NT).
I myself made a small patch to a-raise.c so that it will generate a
traceback
whenever a constraint error is raised. This patch only works on ix86
machines.
Anyway for me it is a big release because it allows me to locate 99% of the
constraint errors.
I use gdb to calculate the exact location of the pc that are reported in
hex in the
traceback.

Wiljan

Re: GNAT exception traceback

[Robert Dewar]

Chris says

<<I have been seeing a lot of e-mails regarding tracebacks.  Correct me
if I am wrong but doesn't the DOS version of GNAT provide tracebacks?
If so then, how hard would it be to incorporate this software into other
releases?
 
Later...>>


Nope, the DOS version does not provide tracebacks. As I have mentioned
before, it is possible to always run under GDB, and to do it in a pretty
transparent manner. What the DOS version provides is some scripts to
make this process pretty transparent (obviously pretty successful, since
Chris thinks the DOS version *does* have tracebacks), and yes, this
approach can be used on any release.

Re: GNAT exception traceback

[Spam Hater]

> Full tracebacks are another matter. There are serious performance penalities
> in making exception occurrences be of arbitrary length, ...

How much would it improve the above "problem" to store the traceback
as a list of addresses, and only convert into human-readable form
when Exception_Information is called?  Not too long ago, someone
helped me do something similar with Alsys, and most of the stack
traces were less than a dozen addresses.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: GNAT exception traceback

[Spam Hater]

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

Definitely.  I can accept the notion that the overhead might be too
high, but I have trouble with the notion (as an outsider)
that it is a tremendous amount of development due to implementation-
dependence.  If gdb can do it on all its supported platforms, could
not some subset of gdb code be jammed into the RTS somewhere?

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: GNAT exception traceback

[Corey Minyard]

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

Re: GNAT exception traceback

[Mats.Weber]

In article <dewar.866305117@merv>,
  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> P.S. the VMS implementation of GNAT *does* provide full tracebacks. That's
> because it is part of the VMS ABI. Too bad that all manufacturers do not
> pay attention to the exception issue when they specify ABI's. Not only
> has Digital always carefully considered these issues, but they have always
> had significant Ada input in the design process, so their design for system
> ABI level handling of exceptions is nicely consistent with the requirements
> in Ada.

That's good news for us since we will continue working with VMS for quite
some time. Just a small question: what does ABI stand for ?

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: GNAT exception traceback

[Chris Sparks (Mr. Ada)]

I have been seeing a lot of e-mails regarding tracebacks.  Correct me
if I am wrong but doesn't the DOS version of GNAT provide tracebacks?
If so then, how hard would it be to incorporate this software into other
releases?

Later...

Chris Sparks

Re: GNAT exception traceback

[Gautier]

Mats.Weber@elca-matrix.ch writes:
>> You need to run gdb to get the traceback. This is easy to do, so it is
>> not clear why you set the precondition of not using it (your question
>> is
>> a bit like saying: can I use GNAT to compile my Ada program without
>> using gcc -- the answer in both cases is no!)
 
> I think this feature (traceback without gdb) would be very useful. It would
> allow us to have a trace of errors occurring at our customers' sites without
> reproducing the bug in our environment, which is often impossible.

The ``ez2load'' GNAT (PC) has a traceback utility without manual use of gdb
- showing parameter values, source code lines (even with generics).

G.

Re: GNAT exception traceback

[Fergus Henderson]

Mats.Weber@elca-matrix.ch writes:

>Just a small question: what does ABI stand for ?

Application Binary Interface.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: GNAT exception traceback

[Robert Dewar]

Mats asks

<<Just a small question: what does ABI stand for?>>

Application Binary Interface -- the definition of how the machine is used
for data representations, calling sequences etc.

Re: GNAT exception traceback

[Robert A Duff]

In article <dewar.866540788@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>First: The slient disappearence of exceptions raised in tasks is *required*
>by the Ada language. The semantics of an unhandled exception is that it
>silently terminates the task in which it appears if this is not the
>environment task. This is not considered an error by the language definition.

Quite true -- the semantics of Ada is that it's not an error to have an
unhandled exception in a task.  Nonetheless, I think the default
behavior of all Ada implementations should be to print out an error
message (including a stack trace-back) when this happens.  You could
even get away with making this the *only* behavior -- nothing in the Ada
RM says the implementation can't print out interesting information
whenever it likes.  I'd be reluctant to go that far, however, because
somebody, somewhere is probably depending on this "silent" behavior.

Given an implementation that doesn't do the nice thing above, one should
put something like "when X: others => Report_Error(X);" at the bottom of
every task.

>(Note: I personally think this is an annoying little mistake in the definition
>of the language, what would be so terrible in requiring programmers to write
>
>   when others => null;
>
>at the top level of a task, if you really want this [typically undesirable]
>behavior?)

Strongly agree.

>That being said, in practice, for programs which do not use Constraint_Error
>as a control structure in the program (one would hope that would be nearly
>all programs, but sadly this is not the case), considering Constraint_Error
>to be always fatal is a very reasonable idea.

In *my* programs, Assertion_Failure is more common than
Constraint_Error, when a bug happens.

- Bob

Re: GNAT exception traceback

[Spam Hater]

> Or, as Wiljan notes, you can hack a-raise.c.
> The idea of using GDB to determine the program location, given a hex
> location, is certainly a reasonable one, though in general you really
> want the traceback which GDB can give you.

gcc C has a builtin function (macro?) for the return address.
Someone sent me C that uses this in a loop to get a stack trace.
Note the parameter to __builtin_frame_address - if I remember 
right, this allows you to say how high up the stack you want 
to go.  If that's right, and if it's not required to be static 
(using Ada's definition of static) then you could increment the 
parameter in a loop.  The  return_addr=  part of the following 
is not portable, but I'm not sure that's needed.

Anyway, for what it's worth (maybe nothing) this might be a 
starting point:

void stack_trace()
{
  char *current_frame
  int return_addr;
  /* obtain current frame address somehow, e.g. inline assembler or
     use gcc __builtin_frame_address. */
  current_frame=__builtin_frame_address(0);
  do {
    return_addr=*(int*)(current_frame+4);  /* obtain return addr */
    /* do whatever you want with the return addr here */
    current_frame=*(char*)current_frame;   /* get frame of next upper
function */
  } while( stack_valid() );
}

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: GNAT exception traceback

[Corey Minyard]

Spam Hater <no.such.user@no.such.com> writes:

> 
> > Or, as Wiljan notes, you can hack a-raise.c.
> > The idea of using GDB to determine the program location, given a hex
> > location, is certainly a reasonable one, though in general you really
> > want the traceback which GDB can give you.
> 
> gcc C has a builtin function (macro?) for the return address.
> Someone sent me C that uses this in a loop to get a stack trace.
> Note the parameter to __builtin_frame_address - if I remember 
> right, this allows you to say how high up the stack you want 
> to go.  If that's right, and if it's not required to be static 
> (using Ada's definition of static) then you could increment the 
> parameter in a loop.  The  return_addr=  part of the following 
> is not portable, but I'm not sure that's needed.
> 
> Anyway, for what it's worth (maybe nothing) this might be a 
> starting point:
> 
> void stack_trace()
> {
>   char *current_frame
>   int return_addr;
>   /* obtain current frame address somehow, e.g. inline assembler or
>      use gcc __builtin_frame_address. */
>   current_frame=__builtin_frame_address(0);
>   do {
>     return_addr=*(int*)(current_frame+4);  /* obtain return addr */
>     /* do whatever you want with the return addr here */
>     current_frame=*(char*)current_frame;   /* get frame of next upper
> function */
>   } while( stack_valid() );
> }

This function will only work on some machines, such as the i386.  It
will not work on machines that do wierd things with stack frames, such
as HPPA and Sparc.  Also, some stacks grow towards larger numbers,
some towards smaller ones.

A couple of more notes on tracebacks from someone who has done a lot
in this area:

On Sparcs, tracebacks are very difficult because you have to "walk"
the register window backwards.  The return address is stored in a
register and may or may not be on the stack when working back on the
stack.  Also, interrupts MUST be turned off during a stack traceback
or the stack can be corrupted by an interrupt since the Sparc uses the
next available register frame on the user stack for the interrupt;
this means in Unix it always involves a system call on a Sparc to get
a traceback.  Don't complain to me about the architecture of this, I
hate it, too.

On HPPA (on HPUX, at least), there are different types of procedures
with different types of return mechanisms.  The only reliable way to
know how to get a stack traceback is to look at the program's symbol
table (which is not normally in memory) to determine the procedure
type!  Even worse than a Sparc!

Tracebacks used to be simple things to do, but some RISC chips have
really done some wierd things in this area.  Be careful not to get
into the "everything's a ..." mentality.

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

Re: GNAT exception traceback

[Spam Hater]

Corey Minyard wrote:
> 
> Wes <wwgrol AT pseserv3.fw.hac.com> writes:
> 
> > > Or, as Wiljan notes, you can hack a-raise.c.
> > > The idea of using GDB to determine the program location, given a hex
> > > location, is certainly a reasonable one, though in general you really
> > > want the traceback which GDB can give you.
> >
> > gcc C has a builtin function (macro?) for the return address.
> > Someone sent me C that uses this in a loop to get a stack trace.
> > Note the parameter to __builtin_frame_address - if I remember
> > right, this allows you to say how high up the stack you want
> > to go.  If that's right, and if it's not required to be static
> > (using Ada's definition of static) then you could increment the
> > parameter in a loop.  The  return_addr=  part of the following
> > is not portable, but I'm not sure that's needed.
> >
> > Anyway, for what it's worth (maybe nothing) this might be a
> > starting point:
> >
> > void stack_trace()
> > {
> >   char *current_frame
> >   int return_addr;
> >   /* obtain current frame address somehow, e.g. inline assembler or
> >      use gcc __builtin_frame_address. */
> >   current_frame=__builtin_frame_address(0);
> >   do {
> >     return_addr=*(int*)(current_frame+4);  /* obtain return addr */
> >     /* do whatever you want with the return addr here */
> >     current_frame=*(char*)current_frame;   /* get frame of next upper
> > function */
> >   } while( stack_valid() );
> > }
> 
> This function will only work on some machines, such as the i386.  It

Well, I can believe that.  
How about (my C is terrible, so use your imagination):

for (i=0; top_of_stack_detected(); i++)
   stack[i] = __builtin_frame_address(i);
   /* I'm not sure if my assumption is correct that BFA(i) gives
      the i-th stack frame from the current.  If it does, then
      implementation-specific files in gcc handle the details:
      find <gcc-dir> -name "*tdep*" -exec grep -il stack {} \;    */

> will not work on machines that do wierd things with stack frames, such
> as HPPA and Sparc.  Also, some stacks grow towards larger numbers,
> some towards smaller ones.
> 
> A couple of more notes on tracebacks from someone who has done a lot
> in this area:
> 
> On Sparcs, tracebacks are very difficult because you have to "walk"
> the register window backwards.  The return address is stored in a
> register and may or may not be on the stack when working back on the
> stack.  Also, interrupts MUST be turned off during a stack traceback
> or the stack can be corrupted by an interrupt since the Sparc uses the
> next available register frame on the user stack for the interrupt;
> this means in Unix it always involves a system call on a Sparc to get
> a traceback.  Don't complain to me about the architecture of this, I
> hate it, too.

Someone gave me SPARC assembler that allegedly works reliably 
when linked into a Verdix Ada program.  I am not at liberty to
release it, though, unless the originator reads this and says it's OK.

> On HPPA (on HPUX, at least), there are different types of procedures
> with different types of return mechanisms.  The only reliable way to
> know how to get a stack traceback is to look at the program's symbol
> table (which is not normally in memory) to determine the procedure
> type!  Even worse than a Sparc!

With HPUX on PA RISC boxes, some C code I received from yet another
kind soul has worked reliably for me when linked into Alsys programs.

Pentium with SCO Unix is one I haven't done, but would like to.
Note that I am not claiming any expertise, just stating what has
worked for me and others and making some wild guesses from that
(in hopes that folks like Corey will keep on pointing out the bugs
in the idea).

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: GNAT exception traceback

[Robert Dewar]

Wiljan said

<<Note that this will only allow to get to the exception raised by the main
program.
When exceptions happen in tasks they simply disappear without a message
or anything from the program (at least on NT).
I myself made a small patch to a-raise.c so that it will generate a
traceback
whenever a constraint error is raised. This patch only works on ix86
machines.>>


A couple of points.

First: The slient disappearence of exceptions raised in tasks is *required*
by the Ada language. The semantics of an unhandled exception is that it
silently terminates the task in which it appears if this is not the
environment task. This is not considered an error by the language definition.

(Note: I personally think this is an annoying little mistake in the definition
of the language, what would be so terrible in requiring programmers to write

   when others => null;

at the top level of a task, if you really want this [typically undesirable]
behavior?)

That being said, in practice, for programs which do not use Constraint_Error
as a control structure in the program (one would hope that would be nearly
all programs, but sadly this is not the case), considering Constraint_Error
to be always fatal is a very reasonable idea.

Two ways of persuing this are to always run under control of GDB setting
a conditional breakpoint on __gnat_raise that will break only if the
exception is CE, or more directly (and still catching nearly all cases)
by breaking on the constraint error entry directly.

Or, as Wiljan notes, you can hack a-raise.c.
The idea of using GDB to determine the program location, given a hex
location, is certainly a reasonable one, though in general you really
want the traceback which GDB can give you.

Re: GNAT exception traceback

[Robert Dewar]

<<How much would it improve the above "problem" to store the traceback
as a list of addresses, and only convert into human-readable form
when Exception_Information is called?  Not too long ago, someone
helped me do something similar with Alsys, and most of the stack
traces were less than a dozen addresses.>>

That's obvious easier, but you still need to be able to unwind the stack,
and in some ABI's that is quite complex.

Re: GNAT exception traceback

[Robert Dewar]

Wes says

<<Definitely.  I can accept the notion that the overhead might be too
high, but I have trouble with the notion (as an outsider)
that it is a tremendous amount of development due to implementation-
dependence.  If gdb can do it on all its supported platforms, could
not some subset of gdb code be jammed into the RTS somewhere?>>

Feel free to jam away :-)

Seriously, this is a very big project, for all sorts of reasons. Wes, if
you do dig into it, you will quickly discover why. Basically the devil is
in the details as usual, but in this case, the details are very considerable.

Here is a little one: you need to have access to the debugging information
from within the program if you use this approach, and indeed you will need
large amounts of space to read in this debugging information (we hope that
the traceback you are trying give is not for Storage_Error). But getting
your hands on this information is not easy. But that's just for starters.


Whenever you have trouble with someone saying that X is a lot of work, and
you know nothing much about X, then probably the first step in verifying
the reasonableness of your trouble is to learn about X. So my invitation 
is as follows: dig away in the GDB code, and if you see a way of doing
this as simply as you feel should be possible, by all means suggest it!

Robert

Re: GNAT exception traceback

[Robert Dewar]

<<How much would it improve the above "problem" to store the traceback
as a list of addresses, and only convert into human-readable form
when Exception_Information is called?  Not too long ago, someone
helped me do something similar with Alsys, and most of the stack
traces were less than a dozen addresses.>>

Notice that this would be pretty easy once you have the new exception
implementation, since that has to be able to unwind the stack in any case,
so it already faces this tough problem (which is why this improved
exception implementation has not appeared yet!)

Re: GNAT exception traceback

[Robert Dewar]

Gautier says

<<The ``ez2load'' GNAT (PC) has a traceback utility without manual use of gdb
- showing parameter values, source code lines (even with generics).>>

Notice the very important qualification ("manual") here. Of course this
traceback *does* use GDB, and is a demonstration of the fact that such use
of GDB can in fact be made quite transparent if you wish (several people
have written to me to tell me that DOS gives tracebacks without using GDB :-)

Re: GNAT exception traceback

[Spam Hater]

> __builtin_frame_address() does not take variables (I played with it to
> find this out :-).  And, on the Sparc, having the frame address does
> not give you the return address.

Oh.  Well, there you have it (or don't have it).

> > Someone gave me SPARC assembler that allegedly works reliably
> > when linked into a Verdix Ada program.  I am not at liberty to
> > release it, though, unless the originator reads this and says it's OK.
> 
> I assume you mean a SPARC traceback facility :-).  Yes, there is a
> system call you can make under Solaris and SunOS to get this
> information; that is what I would expect it would use.  If on a
> real-time platform, you can lock out interrupts and do the trace
> yourself.  I have code for both of these, but they are both extremely
> slow.

No system call or any other call.  40 lines of assembler, 
consisting of a little setup and a loopof nine instructions.  
The originator also claims it's fast.  I didn't think to ask 
whether it is Verdix specific.

> > With HPUX on PA RISC boxes, some C code I received from yet another
> > kind soul has worked reliably for me when linked into Alsys programs.
> 
> It may be that the Alsys compiler only uses one type of return
> mechanism and it can be traced by reliably.  I worked and worked and
> finally asked HP; they told me (and pointed me to the place in the
> manual with the information) about the difficulty when using their C
> compiler.  GCC seems to do the same thing.

I should have said that I had also tested it in a _few_ C programs.
Perhaps I should try more.
 
> > Pentium with SCO Unix is one I haven't done, but would like to.
> > Note that I am not claiming any expertise, just stating what has
> > worked for me and others and making some wild guesses from that
> > (in hopes that folks like Corey will keep on pointing out the bugs
> > in the idea).
> 
> SCO on Pentium should be easy, just the same as Linux on Pentium, the
> original code you posted will work.

Except that we may not always use gcc.  (Plus they've decided to drop
SCO and go to Windoze NT. Ugh!)

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: GNAT exception traceback

[Tom Moran]

As I recall Meridian Ada 83 on the Mac gave at least a one line
traceback telling where in the source code the exception occured.  Alsys
ActivAda Ada 83 on Windows similarly, Janus Ada 83 and 95 on PCs a full
traceback with source line references.  Why is it so hard for brand new
compilers to do what old ones have long done?  Have source code
references and long tracebacks been traditional or not on Unix
platforms?

Re: GNAT exception traceback

[Corey Minyard]

Spam Hater <no.such.user@no.such.com> writes:
> > This function will only work on some machines, such as the i386.  It
> 
> Well, I can believe that.  
> How about (my C is terrible, so use your imagination):
> 
> for (i=0; top_of_stack_detected(); i++)
>    stack[i] = __builtin_frame_address(i);
>    /* I'm not sure if my assumption is correct that BFA(i) gives
>       the i-th stack frame from the current.  If it does, then
>       implementation-specific files in gcc handle the details:
>       find <gcc-dir> -name "*tdep*" -exec grep -il stack {} \;    */

__builtin_frame_address() does not take variables (I played with it to
find this out :-).  And, on the Sparc, having the frame address does
not give you the return address.

> 
> Someone gave me SPARC assembler that allegedly works reliably 
> when linked into a Verdix Ada program.  I am not at liberty to
> release it, though, unless the originator reads this and says it's OK.

I assume you mean a SPARC traceback facility :-).  Yes, there is a
system call you can make under Solaris and SunOS to get this
information; that is what I would expect it would use.  If on a
real-time platform, you can lock out interrupts and do the trace
yourself.  I have code for both of these, but they are both extremely
slow.

> 
> > On HPPA (on HPUX, at least), there are different types of procedures
> > with different types of return mechanisms.  The only reliable way to
> > know how to get a stack traceback is to look at the program's symbol
> > table (which is not normally in memory) to determine the procedure
> > type!  Even worse than a Sparc!
> 
> With HPUX on PA RISC boxes, some C code I received from yet another
> kind soul has worked reliably for me when linked into Alsys programs.

It may be that the Alsys compiler only uses one type of return
mechanism and it can be traced by reliably.  I worked and worked and
finally asked HP; they told me (and pointed me to the place in the
manual with the information) about the difficulty when using their C
compiler.  GCC seems to do the same thing.

> Pentium with SCO Unix is one I haven't done, but would like to.
> Note that I am not claiming any expertise, just stating what has
> worked for me and others and making some wild guesses from that
> (in hopes that folks like Corey will keep on pointing out the bugs
> in the idea).

SCO on Pentium should be easy, just the same as Linux on Pentium, the
original code you posted will work.

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

Re: GNAT exception traceback

[Richard Kenner]

In article <33A6A725.3BD0@no.such.com> Spam Hater <no.such.user@no.such.com> writes:
>gcc C has a builtin function (macro?) for the return address.
>Someone sent me C that uses this in a loop to get a stack trace.
>Note the parameter to __builtin_frame_address - if I remember 
>right, this allows you to say how high up the stack you want 
>to go.

That's right, but many (if not most) implementations of this builtin
are incorrect for non-zero operands.  As you point out, implementing this
function for arbitrary values is equivalent to knowing how to do a full
traceback, which is a very hard task.  These builtins dated back to CISC
days when this was straightforward.

In GCC 2.8.0, these functions will be involved in part of an exception
system that has at least some of this capability, but they are not
recommended for use by programmers with other than an argument of
zero.  They were never documented.

Re: GNAT exception traceback

[Samuel Tardieu]

Wes> Definitely.  I can accept the notion that the overhead might be
Wes> too high, but I have trouble with the notion (as an outsider)
Wes> that it is a tremendous amount of development due to
Wes> implementation- dependence.  If gdb can do it on all its
Wes> supported platforms, could not some subset of gdb code be jammed
Wes> into the RTS somewhere?

gdb is able to read a bunch of different debugging formats, and has a
lot of code which is implementation dependent.

However, it is very easy to get the traceback for the ELF format which 
can be found on many machines. Look at "plumber" sources, and see how
it does extract the traceback. However, that requires reading the
program itself to parse ELF headers and structure, and this can be
very time and CPU consuming.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: GNAT exception traceback

[Richard Kenner]

In article <33A5A600.298A@no.such.com> Spam Hater <no.such.user@no.such.com> writes:
>Definitely.  I can accept the notion that the overhead might be too
>high, but I have trouble with the notion (as an outsider)
>that it is a tremendous amount of development due to implementation-
>dependence.  If gdb can do it on all its supported platforms, could
>not some subset of gdb code be jammed into the RTS somewhere?

No.

gdb (and all debuggers) have access to parts of the executable that aren't
loaded when the program is run, so they are not accessible to the RTS 
unless it also reads the executable file (which it would then have to find).
Also, this requires quite a large subset of gdb code, including all of the
systems-specific configuration information.

Re: GNAT exception traceback

[Corey Minyard]

I'd take this to email, but there is no mail address anywhere in your
post!

Spam Hater <no.such.user@no.such.com> writes:
> 
> > > Someone gave me SPARC assembler that allegedly works reliably
> > > when linked into a Verdix Ada program.  I am not at liberty to
> > > release it, though, unless the originator reads this and says it's OK.
> > 
> > I assume you mean a SPARC traceback facility :-).  Yes, there is a
> > system call you can make under Solaris and SunOS to get this
> > information; that is what I would expect it would use.  If on a
> > real-time platform, you can lock out interrupts and do the trace
> > yourself.  I have code for both of these, but they are both extremely
> > slow.
> 
> No system call or any other call.  40 lines of assembler, 
> consisting of a little setup and a loopof nine instructions.  
> The originator also claims it's fast.  I didn't think to ask 
> whether it is Verdix specific.

I would really like to see it, if you could get permission to release
it.  It would make some people at work pretty happy.  If it was not
Verdix specific it would prove the Sparc manuals wrong, but that
wouldn't bother me.

> 
> > > With HPUX on PA RISC boxes, some C code I received from yet another
> > > kind soul has worked reliably for me when linked into Alsys programs.
> > 
> > It may be that the Alsys compiler only uses one type of return
> > mechanism and it can be traced by reliably.  I worked and worked and
> > finally asked HP; they told me (and pointed me to the place in the
> > manual with the information) about the difficulty when using their C
> > compiler.  GCC seems to do the same thing.
> 
> I should have said that I had also tested it in a _few_ C programs.
> Perhaps I should try more.

I'd like to see that code, too, if possible.

>  
> > > Pentium with SCO Unix is one I haven't done, but would like to.
> > > Note that I am not claiming any expertise, just stating what has
> > > worked for me and others and making some wild guesses from that
> > > (in hopes that folks like Corey will keep on pointing out the bugs
> > > in the idea).
> > 
> > SCO on Pentium should be easy, just the same as Linux on Pentium, the
> > original code you posted will work.
> 
> Except that we may not always use gcc.  (Plus they've decided to drop
> SCO and go to Windoze NT. Ugh!)

The mechanism is generally same for x86 Unix no matter what the
compiler.  I can't speek for windoze, though.

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

Re: GNAT exception traceback

[Michael F Brenner]

R. Dewar:
>First: The slient disappearence of exceptions raised in tasks is *required*
>by the Ada language. The semantics of an unhandled exception is that it
>silently terminates the task in which it appears if this is not the
>environment task. This is not considered an error by the language definition.

R. Duff:
>Quite true -- the semantics of Ada is that it's not an error to have an
>unhandled exception in a task.  Nonetheless, I think the default
>behavior of all Ada implementations should be to print out an error
>message (including a stack trace-back) when this happens.  You could
>even get away with making this the *only* behavior -- nothing in the Ada
>RM says the implementation can't print out interesting information
>whenever it likes.  I'd be reluctant to go that far, however, because
>somebody, somewhere is probably depending on this "silent" behavior.

Depending on this silent behavior? The only argument against having
the ability to generate a traceback given in this thread was 
that it would take a lot of memory. Other, unspoken arguments 
similarly have nothing to do with people depending on not being
able to get the tracebacks at their option: (a) embedded systems
without neither monitor nor file system nor Net connection might
give a problem to compiler vendors who are not creative enough
to program this option in a manner compatible to the available
radio controlled hardware on the space ship; (b) tasks which
are aborted or which terminate abnormally might have been
starved off by a main program (think of obsolete species
whose societies evolve to take up to much of the resources
of the planet so they get calamatied away right in the middle
of their supposed evolution), and that main program does not care
about any appeals from them, however, programmers who arent part of
that great green ooze of evolution, might wish to know why and how 
they got starved off for anthropological reasons;
(c) the great beauty of the intertwining of the two major cables
(mega-threads) which make up comp.lang.ada, namely 
comp.style.ada and comp.fast.ada, which contrast the efficiency
versus the stylistic aesthetics, are twisted in such a way
that efficiency always wins, either by permitting the language
to do things the efficient way, or by being a source of
whining on the part of the efficienados (to coin a word :).

As long as it remained an option, and did not disturb the
many users of commercial products who do not wish to know
why their mouse hung up, there is nothing in the manual that
forbids a compiler/runtime option to generate tracebacks
for either the main program or tasks. 

In addition, there is nothing that prevents more accurate
tracebacks, better control over which exceptions are
treated as fatal errors for debugging purposes versus
which are just handled.           

Re: GNAT exception traceback

[Chris Sparks (Mr. Ada)]

Rober Dewar says:

> Nope, the DOS version does not provide tracebacks. As I have mentioned
> before, it is possible to always run under GDB, and to do it in a
> pretty transparent manner. What the DOS version provides is some
> scripts to make this process pretty transparent (obviously pretty
> successful, since Chris thinks the DOS version *does* have
> tracebacks), and yes, this approach can be used on any release.

Who would be the contact to get help on this scripting system?  I may
want to perform a similar effort to get Linux to do the same.

Chris Sparks

Re: GNAT exception traceback

[Geert Bosch]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
 ``Here is a little one: you need to have access to the debugging information
   from within the program if you use this approach, and indeed you will need
   large amounts of space to read in this debugging information (we hope that
   the traceback you are trying give is not for Storage_Error). But getting
   your hands on this information is not easy. But that's just for starters.''

Having the capability to do a full trace-back of the stack is also
very useful for other purposes. For implementing "exact" garbage 
collection for example, having a good stack traceback is almost
necessary. 

There are implementations of garbage collectors that are completely
based on generating scanning procedures from the debugging information.
I think this is a better approach for GC than either using conservative
GC or changing the compiler too much.

Regards,
   Geert

Re: GNAT exception traceback

[Robert Dewar]

Tom Moran said

<<As I recall Meridian Ada 83 on the Mac gave at least a one line
traceback telling where in the source code the exception occured.  Alsys
ActivAda Ada 83 on Windows similarly, Janus Ada 83 and 95 on PCs a full
traceback with source line references.  Why is it so hard for brand new
compilers to do what old ones have long done?  Have source code
references and long tracebacks been traditional or not on Unix
platforms?>>

It is often not hard to do for one particular architecture, and the PC
architecture is a particularly easy one to deal with.

The difficulty is in implementing this in anything like a machine dependent
fashion.

The reason that there are so many GNAT ports today is that the entire
phiolosophy of GCC has been to be extremely antagonistic to the
introduction of highly machine dependent stuff into the system!

Re: GNAT exception traceback

[Robert Dewar]

Wes says

<<No system call or any other call.  40 lines of assembler, 
consisting of a little setup and a loopof nine instructions.  
The originator also claims it's fast.  I didn't think to ask 
whether it is Verdix specific.>>

Seems dubious that it handles all register windows cases correctly to me!

Re: GNAT exception traceback

[Richard Kenner]

In article <33A85168.4E1A@no.such.com> Spam Hater <no.such.user@no.such.com> writes:
>No system call or any other call.  40 lines of assembler, 
>consisting of a little setup and a loopof nine instructions.  
>The originator also claims it's fast.  I didn't think to ask 
>whether it is Verdix specific.

In order to get a traceback on a Sparc running a standard operating
system, you *must* do a system call.  Otherwise, the code may be very
fast, but is not correct.

Re: GNAT exception traceback

[Geert Bosch]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

   No, that's the point, you can't look at the call stack in a core
   dump, because by the time you know an exception is unhandled,
   it's too late,

I have made a little patch to a-raise.c so __gnat_unhandled_exception
unwinds the stack and writes all return addresses to stderr. This
works without any problems and I was surprised how easy this was
to do. 

Regards,
   Geert

Re: GNAT exception traceback

[Michael F Brenner]

    > I have made a little patch to a-raise.c so __gnat_unhandled_exception
    > ... to unwind the stack and print the traceback

Could you please post this patch?

Re: GNAT exception traceback

[Robert Dewar]

iGeert says

<<I have made a little patch to a-raise.c so __gnat_unhandled_exception
unwinds the stack and writes all return addresses to stderr. This
works without any problems and I was surprised how easy this was
to do.
>>

Sorry, this just does not work, in the general case, when control
is passed to __gnat_unhandled_exception is called, the stack has
already been completely destroyed.

yes it will work in trivial cases with no exception frames around,
that is probably what is confusing you.