About static libraries and Debian policy

About static libraries and Debian policy

[Dmitry A. Kazakov]

http://people.debian.org/~lbrenta/debian-ada-policy.html

requires no static libraries. Is that consistent with GNAT symbolic
traceback, which for some unclear reasons is not included into GNAT
relocatable RTL.

BTW, Why there should be no traceback when relocatable libraries are used? 

What would happen if g-trasym.o (symbolic traceback) were put into a static
library and then linked together with relocatable RTL?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About static libraries and Debian policy

[sjw]

On May 14, 2:16 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> http://people.debian.org/~lbrenta/debian-ada-policy.html
>
> requires no static libraries. Is that consistent with GNAT symbolic
> traceback, which for some unclear reasons is not included into GNAT
> relocatable RTL.
>
> BTW, Why there should be no traceback when relocatable libraries are used?

The problem is, I think, that the GNAT RTL (libgnat, libgnarl) isn't
compiled with debug (-g), so there are no symbols available to
interpret the traceback.

This was certainly true with VxWorks static libraries a while back,
while we were compiling our own we used -g which allowed us to use
vxaddr2line and trace into the RTS. Since we changed to using the
standard RTS + changes compiled using powerpc-wrs-vxworks-gnatmake -a
I can't say we've missed the facility.

> What would happen if g-trasym.o (symbolic traceback) were put into a static
> library and then linked together with relocatable RTL?

I don't know whether you can debug into or get traceback from inside a
dynamic library. Probably depends on the target OS.

Re: About static libraries and Debian policy

[Dmitry A. Kazakov]

On Fri, 14 May 2010 07:57:49 -0700 (PDT), sjw wrote:

> On May 14, 2:16�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> http://people.debian.org/~lbrenta/debian-ada-policy.html
>>
>> requires no static libraries. Is that consistent with GNAT symbolic
>> traceback, which for some unclear reasons is not included into GNAT
>> relocatable RTL.
>>
>> BTW, Why there should be no traceback when relocatable libraries are used?
> 
> The problem is, I think, that the GNAT RTL (libgnat, libgnarl) isn't
> compiled with debug (-g), so there are no symbols available to
> interpret the traceback.

Maybe, but other shared libraries can well be compiled with -g as well as
the application. But linking them with shared RTL fails if any of them uses
Traceback.Symbolic.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About static libraries and Debian policy

[Ludovic Brenta]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On Fri, 14 May 2010 07:57:49 -0700 (PDT), sjw wrote:
>
>> On May 14, 2:16 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>>> http://people.debian.org/~lbrenta/debian-ada-policy.html
>>>
>>> requires no static libraries.

Yes, it does:

§ 5.3.3 Ada object files [...]
Rule: The -dev package SHALL provide a static library in
/usr/lib/libLIBRARY.a.

>>> Is that consistent with GNAT symbolic
>>> traceback, which for some unclear reasons is not included into GNAT
>>> relocatable RTL.

The debugging symbols are in additional packages with names ending in
-dbg.  Re-read § 5.6 The separate debugging information package and §
6.1 Debugging programs that use shared libraries.

>>> BTW, Why there should be no traceback when relocatable libraries are
>>> used?

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

>> The problem is, I think, that the GNAT RTL (libgnat, libgnarl) isn't
>> compiled with debug (-g), so there are no symbols available to
>> interpret the traceback.

Yes, libgnat is compiled with -g but the debugging information is
detached into the -dbg packages.

> Maybe, but other shared libraries can well be compiled with -g as well
> as the application. But linking them with shared RTL fails if any of
> them uses Traceback.Symbolic.

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 Brenta.

Re: About static libraries and Debian policy

[Dmitry A. Kazakov]

On Fri, 14 May 2010 20:43:27 +0200, Ludovic Brenta wrote:

> � 5.3.3 Ada object files [...]
> Rule: The -dev package SHALL provide a static library in
> /usr/lib/libLIBRARY.a.

OK.

>>>> BTW, Why there should be no traceback when relocatable libraries are
>>>> used?
> 
> Traceback is always available, either in symbolic or numeric form.  To
> get the symbolic form, you need the -dbg package installed.

I meant g-trasym.adb. In Fedora's gcc 4.4 it is in the static library, but
absent in the shared. I don't understand why.

>> Maybe, but other shared libraries can well be compiled with -g as well
>> as the application. But linking them with shared RTL fails if any of
>> them uses Traceback.Symbolic.
> 
> 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.

Does it mean that under Debian g-trasym.adb is in both libraries?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About static libraries and Debian policy

[Ludovic Brenta]

Dmitry A. Kazakov writes:
> On Fri, 14 May 2010 20:43:27 +0200, Ludovic Brenta wrote:
>
>> § 5.3.3 Ada object files [...]
>> Rule: The -dev package SHALL provide a static library in
>> /usr/lib/libLIBRARY.a.
>
> OK.
>
>>>>> BTW, Why there should be no traceback when relocatable libraries are
>>>>> used?
>> 
>> Traceback is always available, either in symbolic or numeric form.  To
>> get the symbolic form, you need the -dbg package installed.
>
> I meant g-trasym.adb. In Fedora's gcc 4.4 it is in the static library, but
> absent in the shared. I don't understand why.

Maybe the Fedora maintainers can explain?

>>> Maybe, but other shared libraries can well be compiled with -g as well
>>> as the application. But linking them with shared RTL fails if any of
>>> them uses Traceback.Symbolic.
>> 
>> 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.
>
> Does it mean that under Debian g-trasym.adb is in both libraries?

Yes.  And they Just Work(tm) as they should :)

-- 
Ludovic Brenta.

Re: About static libraries and Debian policy

[Dmitry A. Kazakov]

On Fri, 14 May 2010 22:38:30 +0200, Ludovic Brenta wrote:

> Dmitry A. Kazakov writes:
>> On Fri, 14 May 2010 20:43:27 +0200, Ludovic Brenta wrote:
>>
>>>>>> BTW, Why there should be no traceback when relocatable libraries are
>>>>>> used?
>>> 
>>> Traceback is always available, either in symbolic or numeric form.  To
>>> get the symbolic form, you need the -dbg package installed.
>>
>> I meant g-trasym.adb. In Fedora's gcc 4.4 it is in the static library, but
>> absent in the shared. I don't understand why.
> 
> Maybe the Fedora maintainers can explain?

From g-trasym.ads:

"On all platforms except VMS, this package is not intended to be used
within a shared library, symbolic tracebacks are only supported for the
main executable and not for shared libraries. You should consider using
gdb to obtain symbolic traceback in such cases."

This reads to me: don't use in a shared library. Maybe they just followed
this advice. I admit, I don't understand the text above. In particular,
since any library is dead without the main executable, comparing them makes
no sense to me.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: About static libraries and Debian policy

[Ludovic Brenta]

Dmitry A. Kazakov writes on comp.lang.ada:
> On Fri, 14 May 2010 22:38:30 +0200, Ludovic Brenta wrote:
>
>> Dmitry A. Kazakov writes:
>>> On Fri, 14 May 2010 20:43:27 +0200, Ludovic Brenta wrote:
>>>
>>>>>>> BTW, Why there should be no traceback when relocatable libraries are
>>>>>>> used?
>>>> 
>>>> Traceback is always available, either in symbolic or numeric form.  To
>>>> get the symbolic form, you need the -dbg package installed.
>>>
>>> I meant g-trasym.adb. In Fedora's gcc 4.4 it is in the static library, but
>>> absent in the shared. I don't understand why.
>> 
>> Maybe the Fedora maintainers can explain?
>
> From g-trasym.ads:
>
> "On all platforms except VMS, this package is not intended to be used
> within a shared library, symbolic tracebacks are only supported for the
> main executable and not for shared libraries. You should consider using
> gdb to obtain symbolic traceback in such cases."
>
> This reads to me: don't use in a shared library. Maybe they just followed
> this advice. I admit, I don't understand the text above. In particular,
> since any library is dead without the main executable, comparing them makes
> no sense to me.

To me this reads: do not call this from a shared library; however your
main program can call this even if it is in a shared libgnat.  There is
no technical reason why g-trasym.adb cannot be compiled with -fPIC and
included in a shared library.  For that matter, if we followed your
interpretation, g-trasym.adb should not be in a static library either.

-- 
Ludovic Brenta.

Re: About static libraries and Debian policy

[Simon Wright]

Ludovic Brenta <ludovic@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.

Re: About static libraries and Debian policy

[Ludovic Brenta]

Simon Wright writes on comp.lang.ada:
> Ludovic Brenta <ludovic@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

-- 
Ludovic Brenta.

Re: About static libraries and Debian policy

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Simon Wright writes on comp.lang.ada:
>> Ludovic Brenta <ludovic@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;
+          }

Re: About static libraries and Debian policy

[Ludovic Brenta]

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.

Re: About static libraries and Debian policy

[Björn Persson]

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

Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)

[Ludovic Brenta]

Björn Persson writes on comp.lang.ada:
> 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)?

Yes.  More precisely, libgnat-4.1-dbg on Etch, libgnat-4.3-dbg on Lenny
and libgnat-4.4-dbg on Squeeze.  If the code names are too confusing,
version numbers are useful, too :)

> 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?

I investigated and discovered this is a genuine bug in the patched
convert_addresses which now expects an additional argument; I never
noticed this upstream change:

    2007-04-06  Olivier Hainque  <hainque@adacore.com>
    
    	* adaint.c:
    	(convert_addresses): Adjust prototype and dummy definition to expect an
    	 extra file_name argument.
    
    	* gmem.c (__gnat_convert_addresses): Wrapper to convert_addresses,
    	filling the now expected file_name argument with the appropriate
    	argv[0] expansion.
    	(__gnat_gmem_a2l_initialize, __gnat_gmem_read_next_frame): Use it.
    	(tracebk): Array of void * instead of char *, corresponding to what
    	 convert_addresses expects.
    	(exename): New static global, to hold the executable file name to be
    	used in all convert_addresses invocations.
    	(gmem_read_backtrace, __gnat_gmem_symbolic): Account for tracebk type
    	change.
    	(__gnat_gmem_a2l_initialize): Resolve exename.
    	(__gnat_convert_addresses): Use exename as the convert_addresses
    	file_name argument.
    
    	* g-trasym.adb (Symbolic_Traceback): Adjust signature of imported
    	"convert_addresses", now expecting a filename argument. Import the
    	necessary entities to compute the filename to use and pass it to
    	convert_addresses.

(Subversion revision 123544 on the trunk).  Consequently I never
adjusted convert_addresses.c accordingly.

On the one hand, this is quite embarrassing as it means that both
gnat-4.3 and gnat-4.4 are broken in this respect.  On the other hand,
since nobody noticed or reported this problem before you and gnat-4.3
has been in Debian since 2008-01-30, I'm starting to wonder whether
symbolic tracebacks are all that useful.

Nevertheless, this deserves a bug in the Debian bug tracking system and
a fix before the release of Squeeze.  Thanks for reporting!

-- 
Ludovic Brenta.

Re: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)

[Alex R. Mosteo]

Ludovic Brenta wrote:

> Björn Persson writes on comp.lang.ada:
>> Ludovic Brenta wrote:
>(...)
> 
> On the one hand, this is quite embarrassing as it means that both
> gnat-4.3 and gnat-4.4 are broken in this respect.  On the other hand,
> since nobody noticed or reported this problem before you and gnat-4.3
> has been in Debian since 2008-01-30, I'm starting to wonder whether
> symbolic tracebacks are all that useful.

I'm not user of the debian packages, but I would be quite lost without full 
stack backtraces.

Alex.

> 
> Nevertheless, this deserves a bug in the Debian bug tracking system and
> a fix before the release of Squeeze.  Thanks for reporting!
> 

Re: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)

[Ludovic Brenta]

Alex R. Mosteo wrote on comp.lang.ada:
> Ludovic Brenta wrote:
> > Björn Persson writes on comp.lang.ada:
> >> Ludovic Brenta wrote:
> >(...)
>
> > On the one hand, this is quite embarrassing as it means that both
> > gnat-4.3 and gnat-4.4 are broken in this respect.  On the other hand,
> > since nobody noticed or reported this problem before you and gnat-4.3
> > has been in Debian since 2008-01-30, I'm starting to wonder whether
> > symbolic tracebacks are all that useful.
>
> I'm not user of the debian packages, but I would be quite lost without full
> stack backtraces.
>
> Alex.
>
>> Nevertheless, this deserves a bug in the Debian bug tracking system and
>> a fix before the release of Squeeze.  Thanks for reporting!

I filed a bug report and am testing a fix; I'll probably upload it on
Tuesday or Wednesday.  See http://bugs.debian.org/582452 and followup
there if you want.

--
Ludovic Brenta.

Re: Symbolic tracebacks on Debian

[Ludovic Brenta]

I wrote on comp.lang.ada:
> I filed a bug report and am testing a fix; I'll probably upload it on
> Tuesday or Wednesday.  Seehttp://bugs.debian.org/582452 and followup
> there if you want.

The fix is now available in Debian unstable as part of gnat-4.4 (=
4.4.4-4)
on most architectures.  It should migrate to testing in 10 days.

--
Ludovic Brenta.

Re: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)

[Dmitry A. Kazakov]

On Thu, 20 May 2010 09:20:25 +0200, Ludovic Brenta wrote:

> On the other hand,
> since nobody noticed or reported this problem before you and gnat-4.3
> has been in Debian since 2008-01-30, I'm starting to wonder whether
> symbolic tracebacks are all that useful.

Symbolic traceback is an integral part of GtkAda contributions. Its trace
window can dump, decode, navigate symbolic traceback. It is essential when
debugging GtkAda programs.

(I didn't use Debian until recent time)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Symbolic tracebacks on Debian

[Stephen Leake]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> On the other hand,
> since nobody noticed or reported this problem before you and gnat-4.3
> has been in Debian since 2008-01-30, I'm starting to wonder whether
> symbolic tracebacks are all that useful.

Because symbolic traceback are not supported on _all_ gnat platforms, I
don't use them on _any_ - that way my code is portable. So I did not
notice this problem.

I dump the stack trace as hex addresses, then later run addr2line
manually if I want the symbolic trace.

--
-- Stephe

Re: Symbolic tracebacks on Debian

[(see below)]

On 21/05/2010 09:52, in article 82bpc8s17m.fsf@stephe-leake.org, "Stephen
Leake" <stephen_leake@stephe-leake.org> wrote:

> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
> 
>> On the other hand,
>> since nobody noticed or reported this problem before you and gnat-4.3
>> has been in Debian since 2008-01-30, I'm starting to wonder whether
>> symbolic tracebacks are all that useful.
> 
> Because symbolic traceback are not supported on _all_ gnat platforms, I
> don't use them on _any_ - that way my code is portable. So I did not
> notice this problem.
> 
> I dump the stack trace as hex addresses, then later run addr2line
> manually if I want the symbolic trace.

Can you say exactly what the steps are to do that?
I've never understood it + therefore never used it.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Symbolic tracebacks on Debian

[Simon Wright]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 21/05/2010 09:52, in article 82bpc8s17m.fsf@stephe-leake.org, "Stephen
> Leake" <stephen_leake@stephe-leake.org> wrote:

>> Because symbolic traceback are not supported on _all_ gnat platforms, I
>> don't use them on _any_ - that way my code is portable. So I did not
>> notice this problem.
>> 
>> I dump the stack trace as hex addresses, then later run addr2line
>> manually if I want the symbolic trace.
>
> Can you say exactly what the steps are to do that?
> I've never understood it + therefore never used it.

You need to call

   GNAT.Exception_Traces.Trace_On
     (Kind => GNAT.Exception_Traces.Unhandled_Raise);

from somewhere in your program and run gnatmake with -bargs -E.

Re: Symbolic tracebacks on Debian

[(see below)]

On 22/05/2010 12:25, in article m2aarsuqis.fsf@pushface.org, "Simon Wright"
<simon@pushface.org> wrote:

> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
> 
>> Can you say exactly what the steps are to do that?
>> I've never understood it + therefore never used it.
> 
> You need to call
> 
>    GNAT.Exception_Traces.Trace_On
>      (Kind => GNAT.Exception_Traces.Unhandled_Raise);
> 
> from somewhere in your program and run gnatmake with -bargs -E.

Many thanks.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Symbolic tracebacks on Debian

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>
>> On 21/05/2010 09:52, in article 82bpc8s17m.fsf@stephe-leake.org, "Stephen
>> Leake" <stephen_leake@stephe-leake.org> wrote:
>
>>> Because symbolic traceback are not supported on _all_ gnat platforms, I
>>> don't use them on _any_ - that way my code is portable. So I did not
>>> notice this problem.
>>> 
>>> I dump the stack trace as hex addresses, then later run addr2line
>>> manually if I want the symbolic trace.
>>
>> Can you say exactly what the steps are to do that?
>> I've never understood it + therefore never used it.
>
> You need to call
>
>    GNAT.Exception_Traces.Trace_On
>      (Kind => GNAT.Exception_Traces.Unhandled_Raise);

I never do this.

> from somewhere in your program and run gnatmake with -bargs -E.

I only do this if I want symbolic traces from the running program, which
I don't anymore.

-- 
-- Stephe

Re: Symbolic tracebacks on Debian

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>
>>> On 21/05/2010 09:52, in article 82bpc8s17m.fsf@stephe-leake.org, "Stephen
>>> Leake" <stephen_leake@stephe-leake.org> wrote:
>>
>>>> Because symbolic traceback are not supported on _all_ gnat platforms, I
>>>> don't use them on _any_ - that way my code is portable. So I did not
>>>> notice this problem.
>>>> 
>>>> I dump the stack trace as hex addresses, then later run addr2line
>>>> manually if I want the symbolic trace.
>>>
>>> Can you say exactly what the steps are to do that?
>>> I've never understood it + therefore never used it.
>>
>> You need to call
>>
>>    GNAT.Exception_Traces.Trace_On
>>      (Kind => GNAT.Exception_Traces.Unhandled_Raise);
>
> I never do this.
>
>> from somewhere in your program and run gnatmake with -bargs -E.
>
> I only do this if I want symbolic traces from the running program, which
> I don't anymore.

If you want _symbolic_ traces you add

   GNAT.Exception_Traces.Set_Trace_Decorator
     (Decorator => GNAT.Traceback.Symbolic.Symbolic_Traceback'Access);

Actually, there is a difference: this code

   with GNAT.Exception_Traces;
   procedure T is
      Foo, Bar : exception;
      task T is
         entry Start;
      end T;
      task body T is
      begin
         accept Start;
         raise Bar;
      end T;
   begin
      GNAT.Exception_Traces.Trace_On
        (Kind => GNAT.Exception_Traces.Unhandled_Raise);
      T.Start;
      raise Foo;
   end T;

results in

   $ ./t

   Unhandled Exception raised
   Exception name: T.FOO
   Message: t.adb:16
   Call stack traceback locations:
   0x100001577 0x10000141b
   task t_0000000100800E00 terminated by unhandled exception
   Exception name: T.BAR
   Message: t.adb:10
   Call stack traceback locations:
   0x100001742 0x10000aa82 0x7fff825fb8b4

whereas with the Trace_On call commented out, it generates

   $ ./t

   Execution terminated by unhandled exception
   Exception name: T.FOO
   Message: t.adb:16
   Call stack traceback locations:
   0x10000157d 0x10000142b

so you get to see the unhandled exceptions in tasks too.

Re: Symbolic tracebacks on Debian

[(see below)]

On 23/05/2010 16:52, in article m2632evcn3.fsf@pushface.org, "Simon Wright"
<simon@pushface.org> wrote:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
> 
>> Simon Wright <simon@pushface.org> writes:

>>> You need to call
>>> 
>>>    GNAT.Exception_Traces.Trace_On
>>>      (Kind => GNAT.Exception_Traces.Unhandled_Raise);
>> 
>> I never do this.
>> 
>>> from somewhere in your program and run gnatmake with -bargs -E.
>> 
>> I only do this if I want symbolic traces from the running program, which
>> I don't anymore.
> 
> If you want _symbolic_ traces you add
> 
>    GNAT.Exception_Traces.Set_Trace_Decorator
>      (Decorator => GNAT.Traceback.Symbolic.Symbolic_Traceback'Access);
> 
> Actually, there is a difference: this code
> 
>    with GNAT.Exception_Traces;
>    procedure T is
>       Foo, Bar : exception;
>       task T is
>          entry Start;
>       end T;
>       task body T is
>       begin
>          accept Start;
>          raise Bar;
>       end T;
>    begin
>       GNAT.Exception_Traces.Trace_On
>         (Kind => GNAT.Exception_Traces.Unhandled_Raise);
>       T.Start;
>       raise Foo;
>    end T;
> 
> results in
> 
>    $ ./t
> 
>    Unhandled Exception raised
>    Exception name: T.FOO
>    Message: t.adb:16
>    Call stack traceback locations:
>    0x100001577 0x10000141b
>    task t_0000000100800E00 terminated by unhandled exception
>    Exception name: T.BAR
>    Message: t.adb:10
>    Call stack traceback locations:
>    0x100001742 0x10000aa82 0x7fff825fb8b4
> 
> whereas with the Trace_On call commented out, it generates
> 
>    $ ./t
> 
>    Execution terminated by unhandled exception
>    Exception name: T.FOO
>    Message: t.adb:16
>    Call stack traceback locations:
>    0x10000157d 0x10000142b
> 
> so you get to see the unhandled exceptions in tasks too.

Are these features enabled in your OS X port, Simon?
-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Symbolic tracebacks on Debian

[Simon Wright]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> Are these features enabled in your OS X port, Simon?

That was a prerelease 4.5.0 -- presently running with my build of the
official GCC release.

So far as I know, these features are the same.. yes, just tried it.

The tracebacks you get with atos are rather opaque, and the tool is too
stupid to work out the architecture for itself ..

   $ atos -o t -arch x86_64 0x100001577 0x10000141b
   _ada_t (in t) (t.adb:16)
   main (in t) (b~t.adb:196)
   $ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
   t__tTKB.2815 (in t) + 86
   system__tasking__stages__task_wrapper (in t) + 418
   0x7fff825fb8b4

Re: Symbolic tracebacks on Debian

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>
>> Are these features enabled in your OS X port, Simon?
>
> That was a prerelease 4.5.0 -- presently running with my build of the
> official GCC release.
>
> So far as I know, these features are the same.. yes, just tried it.
>
> The tracebacks you get with atos are rather opaque, and the tool is too
> stupid to work out the architecture for itself ..
>
>    $ atos -o t -arch x86_64 0x100001577 0x10000141b
>    _ada_t (in t) (t.adb:16)
>    main (in t) (b~t.adb:196)

Good enough for emacs to find and display the source location, which is
all you really need.

-- 
-- Stephe

Re: Symbolic tracebacks on Debian

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>
>>> Are these features enabled in your OS X port, Simon?
>>
>> That was a prerelease 4.5.0 -- presently running with my build of the
>> official GCC release.
>>
>> So far as I know, these features are the same.. yes, just tried it.
>>
>> The tracebacks you get with atos are rather opaque, and the tool is too
>> stupid to work out the architecture for itself ..
>>
>>    $ atos -o t -arch x86_64 0x100001577 0x10000141b
>>    _ada_t (in t) (t.adb:16)
>>    main (in t) (b~t.adb:196)
>
> Good enough for emacs to find and display the source location, which is
> all you really need.

I agree about that one, but the next (from the task which died with an
unhandled exception) was

   $ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
   t__tTKB.2815 (in t) + 86
   system__tasking__stages__task_wrapper (in t) + 418
   0x7fff825fb8b4

I dare say a less trivia example would work better.

Re: Symbolic tracebacks on Debian

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> Simon Wright <simon@pushface.org> writes:
>>
>>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>>
>>>> Are these features enabled in your OS X port, Simon?
>>>
>>> That was a prerelease 4.5.0 -- presently running with my build of the
>>> official GCC release.
>>>
>>> So far as I know, these features are the same.. yes, just tried it.
>>>
>>> The tracebacks you get with atos are rather opaque, and the tool is too
>>> stupid to work out the architecture for itself ..
>>>
>>>    $ atos -o t -arch x86_64 0x100001577 0x10000141b
>>>    _ada_t (in t) (t.adb:16)
>>>    main (in t) (b~t.adb:196)
>>
>> Good enough for emacs to find and display the source location, which is
>> all you really need.
>
> I agree about that one, but the next (from the task which died with an
> unhandled exception) was
>
>    $ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
>    t__tTKB.2815 (in t) + 86
>    system__tasking__stages__task_wrapper (in t) + 418
>    0x7fff825fb8b4
>
> I dare say a less trivia example would work better.

I often find the stack trace from a multitasking program to be pretty
useless. The real problem is in some inner task, but the stack trace you
get is from the environment task.

That's when you have to write code to have each task dump its own stack
when it dies.

And on the gripping hand, stack traces from fully optimized code are
also often useless.

-- 
-- Stephe

Re: Symbolic tracebacks on Debian

[Alex R. Mosteo]

Stephen Leake wrote:

> Simon Wright <simon@pushface.org> writes:
> 
>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>>
>>> Simon Wright <simon@pushface.org> writes:
>>>
>>>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>>>
>>>>> Are these features enabled in your OS X port, Simon?
>>>>
>>>> That was a prerelease 4.5.0 -- presently running with my build of the
>>>> official GCC release.
>>>>
>>>> So far as I know, these features are the same.. yes, just tried it.
>>>>
>>>> The tracebacks you get with atos are rather opaque, and the tool is too
>>>> stupid to work out the architecture for itself ..
>>>>
>>>>    $ atos -o t -arch x86_64 0x100001577 0x10000141b
>>>>    _ada_t (in t) (t.adb:16)
>>>>    main (in t) (b~t.adb:196)
>>>
>>> Good enough for emacs to find and display the source location, which is
>>> all you really need.
>>
>> I agree about that one, but the next (from the task which died with an
>> unhandled exception) was
>>
>>    $ atos -o t -arch x86_64 0x100001742 0x10000aa82 0x7fff825fb8b4
>>    t__tTKB.2815 (in t) + 86
>>    system__tasking__stages__task_wrapper (in t) + 418
>>    0x7fff825fb8b4
>>
>> I dare say a less trivia example would work better.
> 
> I often find the stack trace from a multitasking program to be pretty
> useless. The real problem is in some inner task, but the stack trace you
> get is from the environment task.

This is not my experience. I routinely work with multitasking programs and I 
usually get the full backtrace of the task that has caused the exception. 
Perhaps the architecture has something to do? I use regular x86 linux.

> That's when you have to write code to have each task dump its own stack
> when it dies.
> 
> And on the gripping hand, stack traces from fully optimized code are
> also often useless.

Re: Symbolic tracebacks on Debian

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> I often find the stack trace from a multitasking program to be pretty
> useless. The real problem is in some inner task, but the stack trace
> you get is from the environment task.
>
> That's when you have to write code to have each task dump its own
> stack when it dies.

Unless you add (as I said above)

   GNAT.Exception_Traces.Trace_On
     (Kind => GNAT.Exception_Traces.Unhandled_Raise);

I think this may not work as advertised (or, possibly more annoying, may
be unreliable) on older GNATs.

Re: Symbolic tracebacks on Debian

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> I often find the stack trace from a multitasking program to be pretty
>> useless. The real problem is in some inner task, but the stack trace
>> you get is from the environment task.
>>
>> That's when you have to write code to have each task dump its own
>> stack when it dies.
>
> Unless you add (as I said above)
>
>    GNAT.Exception_Traces.Trace_On
>      (Kind => GNAT.Exception_Traces.Unhandled_Raise);
>
> I think this may not work as advertised (or, possibly more annoying, may
> be unreliable) on older GNATs.

The description of that feature makes no mention of tasking. I'll have
to try it.

-- 
-- Stephe

Re: Symbolic tracebacks on Debian

[Stephen Leake]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>
>>> On 21/05/2010 09:52, in article 82bpc8s17m.fsf@stephe-leake.org, "Stephen
>>> Leake" <stephen_leake@stephe-leake.org> wrote:
>>
>>>> Because symbolic traceback are not supported on _all_ gnat platforms, I
>>>> don't use them on _any_ - that way my code is portable. So I did not
>>>> notice this problem.
>>>> 
>>>> I dump the stack trace as hex addresses, then later run addr2line
>>>> manually if I want the symbolic trace.
>>>
>>> Can you say exactly what the steps are to do that?
>>> I've never understood it + therefore never used it.
>>
>> You need to call
>>
>>    GNAT.Exception_Traces.Trace_On
>>      (Kind => GNAT.Exception_Traces.Unhandled_Raise);
>
> I never do this.
>
>> from somewhere in your program and run gnatmake with -bargs -E.
>
> I only do this if I want symbolic traces from the running program, which
> I don't anymore.

Sorry, I was mistaken; -bars -E is required for numeric tracebacks. It's
been too long since I looked at the contents of my standard gpr file.

-- 
-- Stephe

Re: Symbolic tracebacks on Debian

[Yannick Duchêne (Hibou57)]

Le Sat, 22 May 2010 13:03:20 +0200, (see below)  
<yaldnif.w@blueyonder.co.uk> a écrit:
>> Because symbolic traceback are not supported on _all_ gnat platforms, I
>> don't use them on _any_ - that way my code is portable. So I did not
>> notice this problem.
>>
>> I dump the stack trace as hex addresses, then later run addr2line
>> manually if I want the symbolic trace.
>
> Can you say exactly what the steps are to do that?
> I've never understood it + therefore never used it.
If you use GPS or don't bother to use when it is needed, here is one tool  
which may help:
http://www.les-ziboux.rasama.org/addr2line2locations-tool-ada-gps-en.html
Comments welcome.

-- 
There is even better than a pragma Assert: a SPARK --# check.

Re: Symbolic tracebacks on Debian

[Björn Persson]

Stephen Leake wrote:

> I dump the stack trace as hex addresses, then later run addr2line
> manually if I want the symbolic trace.

That's what I'm doing and it's not helping. I'm trying to find out why my 
email doorkeeper daemon sometimes crashes. I write the addresses to the log, 
but when I pass them to addr2line it resolves ony those that are in my own 
code. The crashes seem to happen somewhere in one of the libraries I use, 
and addr2line returns only question marks for those addresses. I don't know 
why. Perhaps it doesn't understand separate debug information files?

-- 
Björn Persson
PGP key A88682FD

Re: Symbolic tracebacks on Debian

[Dmitry A. Kazakov]

On Sat, 22 May 2010 15:20:34 +0200, Bj�rn Persson wrote:

> Stephen Leake wrote:
> 
>> I dump the stack trace as hex addresses, then later run addr2line
>> manually if I want the symbolic trace.
> 
> That's what I'm doing and it's not helping. I'm trying to find out why my 
> email doorkeeper daemon sometimes crashes. I write the addresses to the log, 
> but when I pass them to addr2line it resolves ony those that are in my own 
> code. The crashes seem to happen somewhere in one of the libraries I use, 
> and addr2line returns only question marks for those addresses. I don't know 
> why. Perhaps it doesn't understand separate debug information files?

That is the biggest problem when dealing with Gtk. This is why I integrated
symbolic traceback into the GtkAda contributions + trapping of all log
events of the Gtk. When Gtk logs an event (error, warning), I trace the
stack at once. At this point it is still traceable. C stuff is shown as
???, but the Ada's caller's chain is OK. If you let it go further, it would
crash in 80% cases, and the addresses will be guaranteed rubbish at that
point.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)

[Björn Persson]

Ludovic Brenta wrote:

> Björn Persson writes on comp.lang.ada:
>> Is that libgnat-4.3-dbg that needs to be installed (on Etch)?
> 
> Yes.  More precisely, libgnat-4.1-dbg on Etch, libgnat-4.3-dbg on Lenny
> and libgnat-4.4-dbg on Squeeze.  If the code names are too confusing,
> version numbers are useful, too :)

Yeah, I got the names mixed up. Now we can be embarrassed together.

> On the other hand,
> since nobody noticed or reported this problem before you and gnat-4.3
> has been in Debian since 2008-01-30, I'm starting to wonder whether
> symbolic tracebacks are all that useful.

When I first tried to use it and it failed, I thought it had something to do 
with that note in g-trasym.ads about shared libraries. I thought maybe 
symbolic traceback would only work in statically linked programs or 
something. Apparently Dmitry read it in a similar way. Maybe others also 
read it that way, and therefore didn't report the problem.

-- 
Björn Persson
PGP key A88682FD