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.52.183.161 with SMTP id en1mr15288609vdc.3.1416764468422; Sun, 23 Nov 2014 09:41:08 -0800 (PST) X-Received: by 10.140.40.20 with SMTP id w20mr292446qgw.2.1416764468402; Sun, 23 Nov 2014 09:41:08 -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!w8no1847633qac.0!news-out.google.com!w7ni50qay.0!nntp.google.com!w8no1847630qac.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 23 Nov 2014 09:41:08 -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: Subject: Re: How to get nice with GNAT? From: brbarkstrom@gmail.com Injection-Date: Sun, 23 Nov 2014 17:41:08 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:23666 Date: 2014-11-23T09:41:08-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 I'm working in GNAT GPL, so my suggestion may not work with every compiler. On the other hand, in my code, the if following the exception in the procedure is picked up and executed properly. The code doesn't act like the program has to fail if any exception is raised. It may be that the sensible approach is to try this solution on the compiler you have at hand. If it doesn't work, you'll need to do something else. If it does, I think it can be helpful in diagnosing problems, particularly if you have conditions where the system exceptions (like those in the IO_Exceptions package) are not the only ones a particular algorithm might raise. I'm often doing debugging on sequential algorithms. However, sending out a Bounded_String to print may not work well in a concurrent environment. An approach that may be useful (at least for GNAT) would be to assign a numerical code value to the error message. In that case, a procedure might act like a C subroutine that returns a numerical value of 0 if there were no exceptions or some other value if there was one. With some careful system design, it would be possible to arrange for an exception classification. Thus, some exceptions could be classified as fatal and lead to shutdown. Other exceptions could be classified as "nuisances" and logged. The difficulty in dealing with error classification early in the design process is that the design is malleable. Thus, one could either spend a fair amount of development time pinning down the structure of the exceptions or do the formalization after there's some experience. Some kinds of exceptions, such as equipment failures, may be difficult to handle regardless. If the CPU that's executing the procedural code fails in the middle of the procedure (because of a power outage caused by a a failure of the UPS), it's obvious that there won't be an exception handling message coming out of the procedure. However, algorithmic exceptions don't necessarily have that kind of critical character. Bruce B.