Prev: Trying to get A# set up (and failing)
Next: AWS install problems
From: Simon Wright on 16 May 2010 06:13
Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes:

> Simon Wright writes on comp.lang.ada:
>> Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes:
>>
>>> That's because GNAT GPL includes a non-standard 'libaddr2line.a'
>>> produced from binutils (and therefore pure GPL) and calls that to
>>> produce the symbolic tracebacks. GCC (from the FSF) lacks this
>>> library. I patched GCC to use an alternate mechanism instead,
>>> i.e. fork()/exec() and call /usr/bin/addr2line. This restores the
>>> functionality in the FSF version of GNAT.
>>
>> Ludovic, could you point me towards the patch for this? On Mac OS X, we
>> don't have addr2line, the equivalent is atos.
>
> Latest version:
> http://green.ada-france.org:8081/revision/file/adfe332edf9057b6de622519fd9161421c5c9c76/debian/patches/ada-symbolic-tracebacks.diff
>
> HTH

Thanks for that, I'm sure it'll help. As an alternative, could use one
of the GNAT.OS_Lib.Spawn calls?

I notice that towards the end the comment says

+ -- version dependant variants for the option names. Therefore our
+ -- implementation spawns a shell script that does normalization of
+ -- the option and then executes addr2line and communicates with it
+ -- through a bidirectional pipe.

but it looks to me as though it spawns addr2line drectly?

+ char *const argv[] = { "addr2line",
+ exe_name,
+ "--demangle=gnat",
+ "--functions",
+ "--basenames",
+ NULL };
+ char *const envp[] = { NULL };
+ if (execve("/usr/bin/addr2line", argv, envp) < 0) {
+ CLOSE1; CLOSE2;
+ }
From: Ludovic Brenta on 16 May 2010 06:31
Simon Wright writes on comp.lang.ada:
> Thanks for that, I'm sure it'll help. As an alternative, could use one
> of the GNAT.OS_Lib.Spawn calls?

Probably. Other improvements are probably possible, too. I haven't
worked on this in a long, long time (since the GNAT 3.15p days, in
fact).

> I notice that towards the end the comment says
>
> + -- version dependant variants for the option names. Therefore our
> + -- implementation spawns a shell script that does normalization of
> + -- the option and then executes addr2line and communicates with it
> + -- through a bidirectional pipe.
>
> but it looks to me as though it spawns addr2line drectly?
>
> + char *const argv[] = { "addr2line",
> + exe_name,
> + "--demangle=gnat",
> + "--functions",
> + "--basenames",
> + NULL };
> + char *const envp[] = { NULL };
> + if (execve("/usr/bin/addr2line", argv, envp) < 0) {
> + CLOSE1; CLOSE2;
> + }

The comment was the original from Jürgen Pfeifer. I changed the
implementation to not use a shell script but I forgot to update the
comment.

--
Ludovic Brenta.
From: Björn Persson on 19 May 2010 17:59
Ludovic Brenta wrote:

> Traceback is always available, either in symbolic or numeric form. To
> get the symbolic form, you need the -dbg package installed.

Is that libgnat-4.3-dbg that needs to be installed (on Etch)?

I can't get symbolic traceback to work; I get Storage_Error instead. Below
is my test program and how I compile and run it. Do you have any idea of
what's wrong?

with Ada.Text_IO;
with GNAT.Traceback.Symbolic;

procedure Stack_Trace_Test is

Oopsie : Exception;

procedure Eledile is
begin
raise Oopsie with "How unfortunate!";
end Eledile;

procedure Crocophant is
begin
Eledile;
end Crocophant;

begin
Crocophant;
exception
when E : others =>
Ada.Text_IO.Put_Line(GNAT.Traceback.Symbolic.Symbolic_Traceback(E));
end Stack_Trace_Test;

$ gnatmake stack_trace_test.adb -g -bargs -E
gcc-4.3 -c -g stack_trace_test.adb
gnatbind -E -x stack_trace_test.ali
gnatlink stack_trace_test.ali -g
$ ./stack_trace_test

Execution terminated by unhandled exception
Exception name: STORAGE_ERROR
Message: stack overflow (or erroneous memory access)
Call stack traceback locations:
0xb7e7c56b
$ addr2line --functions --exe=stack_trace_test 0xb7e7c56b
??
??:0

--
Björn Persson
PGP key A88682FD
First  |  Prev  | 
Pages: 1 2 3
Prev: Trying to get A# set up (and failing)
Next: AWS install problems