Re: How to get nice with GNAT?

[brbarkstrom@gmail.com]

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

One possibility is to get in the habit of putting exception handling
messages in every procedure interface, as in

procedure DoSomething(stuff;
                      OK      :    out Boolean;
                      Err_Msg :    out Bounded_String);

if DoSomething throws an exception, the calling program can detect
that OK is false and receive a message identifying the cause.
Since the Ada Bounded_Strings package (see the RM) can append strings,
you can return useful diagnostics by stringing together messages like

Err_Msg := Vstring.To_Bounded_String("Error in DoSomething");
Err_Msg := Vstring.Append(Err_Msg, " caused by bad stuff ");
...

I don't know how much overhead this will cause, but if you're working
with complex logic, this approach can help identify where the problem
is occurring.  One advantage is that you can tailor the format and
content of the messages so that you can understand what happened.
With some thought, you could even label the messages and put them
into a catalog for documenting errors on a production version.

Bruce B.