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