Re: GNAT exception traceback

[Corey Minyard <minyard@acm.org>]

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