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: Samuel Tardieu Subject: Re: GNAT exception traceback Date: 1997/06/18 Message-ID: #1/1 X-Deja-AN: 249283005 Sender: tardieu@esmeralda.enst.fr References: <339EFAE3.26C@ccis.adisys.com.au> <33A22F37.41CBA26B@erols.com> <33A5A600.298A@no.such.com> Mail-Copies-To: sam@ada.eu.org Organization: TELECOM Paris Newsgroups: comp.lang.ada Date: 1997-06-18T00:00:00+00:00 List-Id: 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