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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.236.11.194 with SMTP id 42mr15641565yhx.19.1416768944399; Sun, 23 Nov 2014 10:55:44 -0800 (PST) X-Received: by 10.140.41.147 with SMTP id z19mr319634qgz.1.1416768944377; Sun, 23 Nov 2014 10:55:44 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!w8no1863826qac.0!news-out.google.com!w7ni319qay.0!nntp.google.com!s7no1370030qap.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 23 Nov 2014 10:55:44 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=50.111.65.229; posting-account=Ies7ywoAAACcdHZMiIRy0M84lcJvfxwg NNTP-Posting-Host: 50.111.65.229 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <4a90c3ce-58be-49de-9e33-b529dac1737f@googlegroups.com> Subject: Re: How to get nice with GNAT? From: brbarkstrom@gmail.com Injection-Date: Sun, 23 Nov 2014 18:55:44 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:23669 Date: 2014-11-23T10:55:44-08:00 List-Id: On Friday, November 21, 2014 6:41:45 AM UTC-5, Natasha Kerensikova wrote: > Hello, > > I happen to have found a situation in which symbolic traceback is a > great help, but I have been a bit surprise by the (lack of) support in > the platform to which I have access. > > I have been using GNAT.Traceback.Symbolic.Symbolic_Traceback, is there a > more portable way? > > In FreeBSD, with GNAT 4.9.0, I get an output like the following, with > the first line actually repeated about a hundred times: > > BFD: Dwarf Error: found dwarf version '4', this reader only handles version 2 information. > > 0x7e7773 in asis.gela.contexts.open at ??:0 > > 0x78cb43 in asis.ada_environments.open at ??:0 > > 0x46a7da in adactl at ??:0 > > 0x40690e in main at ??:0 > > 0x4069df in <_start> at ??:0 > > 0x800da3ffe in ?? at ??:0 > > In Debian/kFreeBSD, with GNAT 4.6, it looks like the following, which is > what I consider as perfect: > > 0x7fa993 in asis.ada_environments.open at asis-ada_environments.adb:241 > > 0x481a57 in adactl at adactl.adb:90 > > 0x417029 in main at b~adactl.adb:817 > > 0x8015a4347 in ?? at ??:0 > > 0x41706e in <_start> at ??:0 > > In Fedora 20, with GNAT 4.8.3, it looks like the following, which I find > the worst: > > 0x000000000069307D > > 0x00000000004733BD > > 0x0000000000410824 > > 0x0000003CC5A21D63 > > 0x000000000041086F > > 0xFFFFFFFFFFFFFFFE > > Considering the versions, I doubt that's the cause for the discrepancy. > I would rather wager on something related to addr2line. > > As a user, is there something I can do to improve the traceback > representation on those platforms? > Or is it completely in the hands of the GNAT packager/maintainer? > > > Thanks in advance for your help, > Natasha Maybe another way of putting my suggestion is trying to avoid crash dumps if the exception handling allows a more nuanced approach. I haven't seen much discussion in the Ada literature about the structure of error tracking, although a systematic discussion might help reduce the cost of maintenance. I didn't like the C function value returns because a numerical value doesn't give much of a clue about what happened. With the approach I've suggested, the cause of the problem can be understood without a crash dump (most of the time). For example, if the problem is a bad numerical value being passed in, the error message can include the value, as well as its name. Knowing that the input was the problem makes it easier to feel somewhat more confident about the logic of the procedure. Anyway, I'm just trying to make things easier for practical programmers. If this shoe doesn't fit, you aren't required to wear it. Bruce B.