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/17 Message-ID: #1/1 X-Deja-AN: 249132265 Sender: minyard@wf-rch References: <199706131810.OAA07239@seahunt.ctron.com> <01bc7a82$c57186a0$2a208b82@wd> <33A6A725.3BD0@no.such.com> Organization: Wonderforce Research Newsgroups: comp.lang.ada Date: 1997-06-17T00:00:00+00:00 List-Id: Spam Hater 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