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: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: GNAT exception traceback Date: 1997/06/18 Message-ID: <5o8dpm$q0t$1@news.nyu.edu>#1/1 X-Deja-AN: 249303416 References: <33A22F37.41CBA26B@erols.com> <33A5A600.298A@no.such.com> Organization: New York University Ultracomputer Research Lab Newsgroups: comp.lang.ada Date: 1997-06-18T00:00:00+00:00 List-Id: In article <33A5A600.298A@no.such.com> Spam Hater writes: >Definitely. I can accept the notion that the overhead might be too >high, but I have trouble with the notion (as an outsider) >that it is a tremendous amount of development due to implementation- >dependence. If gdb can do it on all its supported platforms, could >not some subset of gdb code be jammed into the RTS somewhere? No. gdb (and all debuggers) have access to parts of the executable that aren't loaded when the program is run, so they are not accessible to the RTS unless it also reads the executable file (which it would then have to find). Also, this requires quite a large subset of gdb code, including all of the systems-specific configuration information.