Re: How to debug?

[Simon Wright <simon@pushface.org>]

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.