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.1 required=5.0 tests=AC_FROM_MANY_DOTS,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: Spam Hater Subject: Re: GNAT exception traceback Date: 1997/06/17 Message-ID: <33A6FAC5.9BB@no.such.com>#1/1 X-Deja-AN: 249160314 Sender: usenet@most.fw.hac.com (News Administration) X-Nntp-Posting-Host: sparc02 References: <199706131810.OAA07239@seahunt.ctron.com> <01bc7a82$c57186a0$2a208b82@wd> <33A6A725.3BD0@no.such.com> Organization: See Warning Below! Newsgroups: comp.lang.ada Date: 1997-06-17T00:00:00+00:00 List-Id: Corey Minyard wrote: > > Wes 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 -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! ----------------------------------------------------------------------