Re: How to debug?

Re: How to debug?

[Jerry van Dijk]

> How do I inspect the call stack (preferably symbolic information i.e. source
> code unit name + line number + subprogram names), upon an unhandled
> exception occurrence?

Maybe you have an installation problem ?

If I follow the instructions in chapter 23.13.2.1 (Tracebacks From Exception 
Occurrences) in the GNAT 3.15p user manual it works:

-------------------------------------------------------------------------------
C:\home\work>cat stb.adb
with Ada.Text_IO;
with GNAT.Traceback.Symbolic;

procedure STB is

   procedure P1 is
   begin
      raise Constraint_Error;
   end P1;

   procedure P2 is
   begin
      P1;
   end P2;

   procedure P3 is
   begin
      P2;
   end P3;

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

C:\home\work>gnatmake -g stb -bargs -E -largs -lgnat -laddr2line -lintl
gcc -c -g stb.adb
gnatbind -aO./ -E -I- -x stb.ali
gnatlink -g -lgnat -laddr2line -lintl stb.ali

C:\home\work>stb
00404F61 in ada.exceptions.process_raise_exception at a-except.adb:1320
004020D7 in <__gnat_rcheck_04> at a-except.adb:592
004015A7 in stb.p1 at stb.adb:8
004015BF in stb.p2 at stb.adb:13
004015D7 in stb.p3 at stb.adb:18
004017F1 in stb at stb.adb:22
004013CF in main at b~stb.adb:168
00401103 in ?? at fake:0
-------------------------------------------------------------------------------

-- 
--  Jerry van Dijk
--  Leiden, Holland 

Re: How to debug?

[Marius Amado Alves]

> C:\home\work>gnatmake -g stb -bargs -E -largs -lgnat -laddr2line -lintl

Thanks. I can see there are some options there that I was not passing and 
surely must. But now I get a host of "undefined reference to 
'system__parameters...'" and "...to 'system__underlying__priorities" messages 
and then gnatlink says "cannot call C:\GNAT\bin\gcc.exe". "*** Link failed."

My command was

gnatmake <unit> -f -g -IMneson -IMneson/ai302 -IAWS/include -IAWS/lib 
-IAWS/components -Io_and_ali_files -i -aOAWS/lib -bargs -E -largs -LAWS/lib 
-laws -lgnat -laddr2line -lintl

I've got GNAT installed at C:\GNAT, and the environment variables include

OS=Windows_NT
Path=C:\GNAT\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\PROGRA~1\ATT\Graphviz\bin;C:\PROGRA~1\ATT\Graphviz\bin\tools
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 11 Stepping 1, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0b01
SystemDrive=C:
SystemRoot=C:\WINDOWS

(They do NOT include ADA_OBJECTS_PATH et al.)

Thanks a lot.

Re: How to debug? (solved)

[Marius Amado Alves]

The Symbolic_Traceback does not work, but the non-symbolic does, and an 
"addr2line.exe" executable exists and works as expected, so I'm using these 
elements to solve the problem. Thanks.

Re: How to debug?

[David C. Hoos]

The Gnat 3.15 User's Guide says under Binder Switches, the following:

Store tracebacks in exception occurrences when the target supports it. This
is the default with the zero cost exception mechanism. This option is
currently supported on the following targets: all x86 ports, Solaris,
Windows, HP-UX, AIX, PowerPC VxWorks and Alpha VxWorks. See also the
packages GNAT.Traceback and GNAT.Traceback.Symbolic for more information.
Note that on x86 ports, you must not use -fomit-frame-pointer gcc option.

I have not tried this on Windows, as almost all of my work is on Unix/Linux
platforms. Putting an exception handler at the end of the main procedure
and at the end of all tasks works very well for me.  These exception
handlers use the SymbolicTraceback facilities.


----- Original Message ----- 
From: "Marius Amado Alves" <maa@liacc.up.pt>
To: <comp.lang.ada@ada-france.org>
Sent: Wednesday, May 05, 2004 12:30 PM
Subject: How to debug?


How do I inspect the call stack (preferably symbolic information i.e. source
code unit name + line number + subprogram names), upon an unhandled
exception
occurrence?

I'm on Windows XP, with GNAT 3.15p. I tried GVD and gdb to no avail (yes,
compiled with the -g option). Would it work on Linux?

Do I have to catch the exception, perhaps just to put a breakpoint in the
handler?

Sometime ago, I think with GNAT 3.13p or 3.14p, I also tried instrumenting
my
code with GNAT's Symbolic_Traceback but it also didn't work. Would it work
now with version 3.15p?

Would GPS do the trick?

Thanks a lot.

/* So far I seem to have been able to produce working Ada programs without a
debugger. I instrument. But now I'm tired. And it's rather irritating that
Ada, GNAT, the 'p' versions, does not facilitate debugging like e.g. the
Borland products did. I miss that aspect of them. I whish there was a Turbo
Ada. */



_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada-france.org
http://www.ada-france.org/mailman/listinfo/comp.lang.ada

Re: How to debug?

[Simon Wright]

"David C. Hoos" <david.c.hoos.sr@ada95.com> writes:

> I have not tried this on Windows, as almost all of my work is on
> Unix/Linux platforms. Putting an exception handler at the end of the
> main procedure and at the end of all tasks works very well for me.
> These exception handlers use the SymbolicTraceback facilities.

You can't use symbolic tracebacks on VxWorks, which is why we always
use the plain ones, even on the development (Windows) platform; no
great pain to decode.

Re: How to debug?

[Marius Amado Alves]

On Wednesday 05 May 2004 19:27, David C. Hoos wrote:
> ...Putting an exception handler at the end of the main procedure
> and at the end of all tasks works very well for me.  These exception
> handlers use the SymbolicTraceback facilities.

That's what I tried before GNAT 3.15p and failed (no traceback). I must have 
done something wrong. I'll try again soon. Thanks.

Re: How to debug?

[Ludovic Brenta]

Marius Amado Alves writes:
> On Wednesday 05 May 2004 19:27, David C. Hoos wrote:
> > ...Putting an exception handler at the end of the main procedure
> > and at the end of all tasks works very well for me.  These exception
> > handlers use the SymbolicTraceback facilities.
> 
> That's what I tried before GNAT 3.15p and failed (no traceback). I must have 
> done something wrong. I'll try again soon. Thanks.

FYI

The GNAT on Debian does not support symbolic tracebacks because this
requires a library called libaddr2line, which is part of the old
version of binutils that was current when GCC 2.8.1 was released.

The binary distribution from ACT ships a binary libaddr2line and does
support symbolic tracebacks.

-- 
Ludovic Brenta.

Re: How to debug?

[Marius Amado Alves]

[On Windows XP, GNAT 3.15p.]

Ok, I've tried Symbolic_Traceback again. It still does not work :-(

Re: How to debug?

[Stephen Leake]

Marius Amado Alves <maa@liacc.up.pt> writes:

> [On Windows XP, GNAT 3.15p.]
> 
> Ok, I've tried Symbolic_Traceback again. It still does not work :-(

Hmm. I just tried it on Windows 2000 with GNAT 3.15p; it did not work.
Apparently 3.15p is broken here.

-- 
-- Stephe

How to debug?

[Marius Amado Alves]

How do I inspect the call stack (preferably symbolic information i.e. source 
code unit name + line number + subprogram names), upon an unhandled exception 
occurrence?

I'm on Windows XP, with GNAT 3.15p. I tried GVD and gdb to no avail (yes, 
compiled with the -g option). Would it work on Linux?

Do I have to catch the exception, perhaps just to put a breakpoint in the 
handler?

Sometime ago, I think with GNAT 3.13p or 3.14p, I also tried instrumenting my 
code with GNAT's Symbolic_Traceback but it also didn't work. Would it work 
now with version 3.15p?

Would GPS do the trick?

Thanks a lot.

/* So far I seem to have been able to produce working Ada programs without a 
debugger. I instrument. But now I'm tired. And it's rather irritating that 
Ada, GNAT, the 'p' versions, does not facilitate debugging like e.g. the 
Borland products did. I miss that aspect of them. I whish there was a Turbo 
Ada. */

Re: How to debug?

[Simon Wright]

Marius Amado Alves <maa@liacc.up.pt> writes:

> How do I inspect the call stack (preferably symbolic information
> i.e. source code unit name + line number + subprogram names), upon
> an unhandled exception occurrence?
> 
> I'm on Windows XP, with GNAT 3.15p. I tried GVD and gdb to no avail
> (yes, compiled with the -g option). Would it work on Linux?
> 
> Do I have to catch the exception, perhaps just to put a breakpoint
> in the handler?

I don't know what 3.15p comes with (being supported makes one forget
this sort of thing), but if it's got GDB in you should be able to say
"break exception" (maybe even "break exception unhandled". You may
have to say "set language ada" first.

This:
   procedure Ex is
      E : exception;
      procedure P (D : Integer) is
      begin
         if D = 0 then
            raise E;
         end if;
         P (D - 1);
      end P;
   begin
      P (3);
   end Ex;
results in this:
   smaug.pushface.org[14]$ /opt/3.15p/bin/gdb ex
   GNU gdb 5.1.1.gnat.3.15p 
   Copyright 2002 Free Software Foundation, Inc.
   Ada Core Technologies version of GDB for GNAT Professional
   GDB is free software, covered by the GNU General Public License, and you are
   welcome to change it and/or distribute copies of it under certain conditions.
   Type "show copying" to see the conditions.
   See your support agreement for details of warranty and support.
   If you do not have a current support agreement, then there is absolutely
   no warranty for this version of GDB. Type show warranty for details.
   This GDB was configured as "i386-pc-linux"...
   (gdb) b exception
   Breakpoint 1 at 0x804a9c2: file a-except.adb, line 1665.
   (gdb) run
   Starting program: /home/simon/tmp/ex 

   Breakpoint 1, EX.E at 0x08049375 in ex.p (d=0) at ex.adb:6
   6                raise E;
   (gdb) bt
   #0  <__gnat_raise_nodefer_with_msg> (e=0x8050c18) at a-except.adb:1665
   #1  0x0804ac7a in <__gnat_raise_with_msg> (e=0x8050c18) at a-except.adb:1844
   #2  0x0804aade in <__gnat_raise_exception> (e=0x8050c18, message=0x804f518)
       at a-except.adb:1704
   #3  0x08049375 in ex.p (d=0) at ex.adb:6
   #4  0x08049385 in ex.p (d=1) at ex.adb:8
   #5  0x08049385 in ex.p (d=2) at ex.adb:8
   #6  0x08049385 in ex.p (d=3) at ex.adb:8
   #7  0x080493c3 in ex () at ex.adb:11
   #8  0x08049335 in main (argc=1, argv=3221223396, envp=3221223404)
       at b~ex.adb:109
   #9  0x4003d280 in __libc_start_main () from /lib/libc.so.6

> Sometime ago, I think with GNAT 3.13p or 3.14p, I also tried
> instrumenting my code with GNAT's Symbolic_Traceback but it also
> didn't work. Would it work now with version 3.15p?

If I change the code above to
   with GNAT.Exception_Traces;
   procedure Ex is
      E : exception;
      procedure P (D : Integer) is
      begin
         if D = 0 then
            raise E;
         end if;
         P (D - 1);
      end P;
   begin
      GNAT.Exception_Traces.Trace_On
        (Kind => GNAT.Exception_Traces.Unhandled_Raise);
      P (3);
   end Ex;
and compile with
   gnatmake -f -g ex -bargs -E
I get
   smaug.pushface.org[16]$ ./ex

   Execution terminated by unhandled exception
   Exception name: EX.E
   Message: ex.adb:7
   Call stack traceback locations:
   0x804c1cb 0x8049377 0x8049387 0x8049387 0x8049387 0x80493cf 0x8049337
and then (this is on Linux, but the Cygwin addr2line works fine)
   smaug.pushface.org[17]$ addr2line -e ex 0x804c1cb 0x8049377 0x8049387 0x8049387 0x8049387 0x80493cf 0x8049337
   /lek.a/gnatmail/manual/build-lek/src/ada/rts/a-except.adb:1320
   /home/simon/tmp/ex.adb:7
   /home/simon/tmp/ex.adb:9
   /home/simon/tmp/ex.adb:9
   /home/simon/tmp/ex.adb:9
   /home/simon/tmp/ex.adb:14
   /home/simon/tmp/b~ex.adb:111

> Would GPS do the trick?

GPS uses GDB to debug so it will behave similarly.

Re: How to debug?

[Matthew Heaney]

Marius Amado Alves <maa@liacc.up.pt> writes:

> How do I inspect the call stack (preferably symbolic information
> i.e. source code unit name + line number + subprogram names), upon an
> unhandled exception occurrence?
> 
> I'm on Windows XP, with GNAT 3.15p. I tried GVD and gdb to no avail
> (yes, compiled with the -g option). Would it work on Linux?

I find the best way is to run gdb from inside emacs.  That works on both
Windows and GNU/Linux.

Just break on an exception, and then get a backtrace when the exception
is raised.

-Matt

Re: How to debug?

[Pascal Obry]

Marius Amado Alves <maa@liacc.up.pt> writes:

> I'm on Windows XP, with GNAT 3.15p. I tried GVD and gdb to no avail (yes, 
> compiled with the -g option). Would it work on Linux?

I can't comment about your specific problem, but definitly this should work.

> Do I have to catch the exception, perhaps just to put a breakpoint in the 
> handler?
> 
> Sometime ago, I think with GNAT 3.13p or 3.14p, I also tried instrumenting
> my  code with GNAT's Symbolic_Traceback but it also didn't work. Would it
> work  now with version 3.15p?

Symbolic_Traceback also works fine with GNAT on Windows.

> Would GPS do the trick?

Yes, and it uses GDB to launch a debug session, the proof that GDB works
just fine :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595