debugging GNAT programs

debugging GNAT programs

[Marc Graham]

To those of you using GNAT, do you have any hints about debugging?
Particularly "unhandled exceptions" (currently, GNAT just prints the
message: terminated due to unhandled exception (or something like
that) and, since it terminated, gdb can't find where the exception was
raised. (Anyway, gdb debugs the generated c code, not the Ada
code. Which makes it pretty useless.)

Of course, if the GNAT folk were to implement Ada.Exceptions, I could
solve this problem myself, (grumble, grumble, he hinted ... ;^} 

e-mail replies preferred. Thanks. 


Marc H. Graham                    Software Engineering Institute
marc@sei.cmu.edu                  Carnegie Mellon University
(412) 268 7784                    Pittsburgh, PA   15213
                   

Re: debugging GNAT programs

[Robert A Duff]

In article <1995Mar2.095243.14051@sei.cmu.edu>,
Marc Graham <marc@sei.cmu.edu> wrote:
>
>To those of you using GNAT, do you have any hints about debugging?

It would be nice if these hints were in the GNAT documentation.

E.g. which routine in the run-time system should one set a breakpoint on
in order to trap unhandled exceptions?

- Bob

Re: debugging GNAT programs

[Pug 156]

I think the release notes or maybe gnatinfo.txt says something about
setting a break point on the run time's raise_exception routine.  See the
notes for the actual name.  Try gnatinfo.txt first, I think its there.

Re: debugging GNAT programs

[Tom Griest]

In article <3j5vvu$6c2@newsbf02.news.aol.com> pug156@aol.com (Pug 156) writes:
>I think the release notes or maybe gnatinfo.txt says something about
>setting a break point on the run time's raise_exception routine.  See the
>notes for the actual name.  Try gnatinfo.txt first, I think its there.


__gnat_raise is only called for unhandled exceptions (which was
the original question).  If you want to catch any exception you 
have to also set a breakpoint on the longjmp routine.  
(I'm not sure that this isn't used for things other than just 
exception propogation, but it seems to work reliably.)

-Tom

Re: debugging GNAT programs

[Bernard Banner]

griest-tom@cs.yale.edu (Tom Griest) writes:
: __gnat_raise is only called for unhandled exceptions (which was
: the original question).  If you want to catch any exception you 
: have to also set a breakpoint on the longjmp routine.  
: (I'm not sure that this isn't used for things other than just 
: exception propogation, but it seems to work reliably.)
: 
: -Tom

__gnat_raise is called on every exception raised whether it is handled or
not. __gnat_unhandled_exception is called only for unhandled exceptions.

Bernard Banner
banner@cs.nyu.edu

Re: debugging GNAT programs

[Tom Griest]

banner@cs.nyu.edu (Bernard Banner) writes:
>griest-tom@cs.yale.edu (Tom Griest) writes:
>: __gnat_raise is only called for unhandled exceptions (which was
>: the original question).  If you want to catch any exception you 
>: have to also set a breakpoint on the longjmp routine.  
>: (I'm not sure that this isn't used for things other than just 
>: exception propogation, but it seems to work reliably.)
>: 
>: -Tom
>
>__gnat_raise is called on every exception raised whether it is handled or
>not. __gnat_unhandled_exception is called only for unhandled exceptions.
>
>Bernard Banner

I remember having a problem catching an exception by just setting
a break on __gnat_raise.  Somehow (either through __gnat_reraise or
a direct reference in the generated code) __gnat_raise_nodefer was getting 
invoked and the longjmp was getting taken without an intervening call
to __gnat_raise.

This was a couple of months ago, so things may be a little different
now.

_tom

Re: debugging GNAT programs

[Keith Thompson]

In <1995Mar2.095243.14051@sei.cmu.edu> marc@sei.cmu.edu (Marc Graham) writes:
> To those of you using GNAT, do you have any hints about debugging?
> Particularly "unhandled exceptions" (currently, GNAT just prints the
> message: terminated due to unhandled exception (or something like
> that) and, since it terminated, gdb can't find where the exception was
> raised. (Anyway, gdb debugs the generated c code, not the Ada
> code. Which makes it pretty useless.)

First of all, there is no generated C code.  The name GNAT (GNU Ada
Translator) is perhaps slightly misleading, but it's a true compiler
that happens to share a backend with several other GNU compilers.

I found this in "using GDB" gnatinfo.txt, which is part of the GNAT
distribution:

> Exceptions can be caught by breaking in the "__gnat_raise" routine and then
> doing a "bt" or "where" command.

(Speaking for nobody as always.)

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.

Re: debugging GNAT programs

[Robert S. White]

In article <D4u3Js.G20@thomsoft.com>, kst@thomsoft.com says...
>In <1995Mar2.095243.14051@sei.cmu.edu> marc@sei.cmu.edu (Marc Graham) writes:
.
>> raised. (Anyway, gdb debugs the generated c code, not the Ada
>> code. Which makes it pretty useless.)
>
>First of all, there is no generated C code.  The name GNAT (GNU Ada
>Translator) is perhaps slightly misleading, but it's a true compiler
>that happens to share a backend with several other GNU compilers.
.
But what is the "b_hello.c" file generated by gnatbl from the hello.ali file
which was generated from the hello.adb (from the GNAT examples) file by gcc?
It sure looks like C code.  Granted the GNU compilers use an intermediate
code which is not C for the optimization pass.  But it sure looks like the 
current GNAT 2.03a for Win NT uses (or generates as an incidental) C source
code.  This step could be enventually skipped IMHO.  I don't have the files
in front of me right now (they are on my home machine), but this is what I
remember from my new experience in the past week with GNAT.

Re: debugging GNAT programs

[Robert Dewar]

The GNAT compiler does NOT generate intermediate C code in either external
source form, or in internal intermediate form. Instead it transforms the
Ada structures to RTL using the GCC Tree, which is capable of representing
semantic structures not representable into C. Translating Ada into C is
a hard task, which involves some fundamental inefficiencies, and it is not
a task that GNAT attempts or has ever attempted. I know a lot of people
get confused on this issue, partly because of the historical meaning of
GCC (GNU C Compiler), partly because of the name GNAT (... Translator),
and partly because, we see now! of the main program.

The main program that is generated by the binder is indeed in C currently,
and it is compiled using the C compiler. It contains nothing more than a series
of elaboration calls and the call to the main program.

On our list of things to do is to have an option saying whether the main
program is to be generated in Ada or C, but that's not done yet!

Anyway, the idea that GDB debugs the generated C code is completely wrong
(unless of course you are debugging the generated main elabroation program).

What *is* true is that gdb thinks it is debugging C code and does not know
anything about Ada. Since the generated Ada code is pretty similar to C code,
this works pretty well (but you have to use && instead of and then when you
type an expression!), and the data structures correspond *pretty* well so
you can definitely do a lot debugging with gdb. THe source positions *do*
properly correspond to the original Ada source code, so the source debugging
works fine.

You do have to know the naming convention (fully qualified names, forced
to lower case, with periods replaced by double underscores). See the
documentation that comes with GNAT for more details.

Obviously it would be nice if gdb knew more about Ada, and Paul Hilfinger
is currently working on a project with gdb to teach it to be more polite
in an Ada environment, but meanwhile, it is definitely a useful tool for
debugging GNAT, the GNAT development team has been using it for this purpose
for nearly two years.

Robert

Re: debugging GNAT programs

[Robert Dewar]

"This step could eventually be skipped IMHO"

The step referred to is generating a source program from the binder for
the main program (although I think the writer also was under the
mis-conception that other Ada compilation went through C).

But with regards to the binder, it is *very* important that source code is
generated, because it means you can step through the elaboration code just
as you would debug any other source code using whatever source level
debugger you normally use for the rest of the program. There have been some
Ada systems which precisely skipped this step, and as a consequence 
debugging the elaboration code could be tricky.

We think it is a definite advantage to generate source for the main program,
and have no intention of changing it. As I mentioned before, we do intend
to have the option of generating the main program in Ada (indeed we will
probably make this the deault), but that's for later. We have introduced
attributes that let an Ada program call the elaboration routines for
packages precisely so that the main program can easily be written in Ada.

Apart from the conceptual clarification of having the Ada main program be
in Ada, there is in some environments a real advantage in disk cache usage
in not having to load the C compiler to compile simple Ada programs. This
point was discussed extensively in a thread on CLA some months ago (along
with an extensive philosophical discussion in which others felt that generating
the main program in C somehow declared that C was a superior language to
Ada -- not quite sure I ever managed to follow that logic, but anyway we
do intend to "fix" this "problem".

Note that we will still leave the option to generate a main program in C, 
because in some mixed language environments this has advantages.

Re: debugging GNAT programs

[kkrieser]

In <3jcmo9$skq@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) writes:
>"This step could eventually be skipped IMHO"
>(along
>with an extensive philosophical discussion in which others felt that generating
>the main program in C somehow declared that C was a superior language to
>Ada -- not quite sure I ever managed to follow that logic, but anyway we
>do intend to "fix" this "problem".

Of course, by that light, machine code is declared as a superior lanquage, since most 
languages, unless interpreted or P-code, are converted into machine code<G>

-----------------------------------------
--  Kevin Krieser
--  Using OS/2 Warp
--  New Address:  kkrieser@ionet.net,
--  or kkrieser@bix.com

Re: debugging GNAT programs

[Robert S. White]

In article <3jcmo9$skq@gnat.cs.nyu.edu>, dewar@cs.nyu.edu says...
>> This step could eventually be skipped IMHO
.
> The step referred to is generating a source program from the binder for
> the main program (although I think the writer also was under the
> mis-conception that other Ada compilation went through C).

But, but, I SAID "GNU compilers use an intermediate code which is not 
C for the optimization pass".  This weekend I did some more RTFM 
(by doing: "gcc --help" getting a nice Windows Help file) and did 
find very clear documentation that GNATBIND generates a C source 
main program for startup and elaboration purposes.  Looking at the 
examples I see that it fetches command line parameters, calls 
elaboration routines, calls the actual Ada program, may call some 
"system__finalization_implementation__" stuff,  calls the C library 
exit() routine to return the program error status and finally has a
table of symbols and objects data.

> But with regards to the binder, it is *very* important that source code is
> generated, because it means you can step through the elaboration code just
> as you would debug any other source code using whatever source level
> debugger you normally use for the rest of the program. There have been some
> Ada systems which precisely skipped this step, and as a consequence 
> debugging the elaboration code could be tricky.

Agreed, in working on embedded systems it seems like the nastiest bugs
(hardest to debug) occur during elaboration.  We always have had at least
an assembler list file of the calls to elaboration routines but users find
it alien to debug problems there rather than in their Ada module.

> We think it is a definite advantage to generate source for the main program,
> and have no intention of changing it. As I mentioned before, we do intend
> to have the option of generating the main program in Ada (indeed we will
> probably make this the deault), but that's for later. We have introduced
> attributes that let an Ada program call the elaboration routines for
> packages precisely so that the main program can easily be written in Ada.

We certainly need source for the main (external wrapper/elaborating) 
program.  I don't care if it is in C or Ada except when I have to train 
software engineers unfamiliar with C in C (yes there are a few!).  It 
is interesting to hear the plans for future GNAT changes in this area.
-------------------------------------------
Robert S. White -- speaking for myself only 
76166.1137@compuserve.com

Re: debugging GNAT programs

[Vladimir Vukicevic]

In article <1995Mar2.095243.14051@sei.cmu.edu> marc@sei.cmu.edu (Marc
Graham) writes:

> To those of you using GNAT, do you have any hints about debugging?
> Particularly "unhandled exceptions" (currently, GNAT just prints
> the message: terminated due to unhandled exception (or something
> like that) and, since it terminated, gdb can't find where the
> exception was raised.

The exception raising routine is called __gnat_raise. Set a breakpoint
there to catch exceptions.

> (Anyway, gdb debugs the generated c code, not the Ada code. Which
> makes it pretty useless.)

The main Ada procedure is called _ada_(procedure_name). If your 'main'
procedure is called FOO, then set a break on _ada_foo to begin debugging
on entry to your program.

Another thing to know is that if you want to step into a dispatching call,
you have to step through some internal gnat procedures which find the address
of the real function in the vtable.

	-- Vladimir Vukicevic
	-- vladimir@intrepid.com

Re: debugging GNAT programs

[Cyrille Comar]

vladimir@speedy.intrepid.com (Vladimir Vukicevic) writes:
: In article <1995Mar2.095243.14051@sei.cmu.edu> marc@sei.cmu.edu (Marc
: Graham) writes:
: > (Anyway, gdb debugs the generated c code, not the Ada code. Which
: > makes it pretty useless.)

I have been extensively debugging GNAT code (written in Ada95) for 2
years with gdb and found it quite useful. The only awkward thing is
that you have to use the C syntax for expressions but this is
managable...

: 
: Another thing to know is that if you want to step into a dispatching call,
: you have to step through some internal gnat procedures which find the address
: of the real function in the vtable.

Vladimir, 
The procedure you are refering to (Get_Prim_Op_Address) is an artifact
that should be invisible to the direct user and will be as soon as
"inter-module inlining" is working: all the Dispatch-Table access
functions will be unconditionnally inlined... The only purpose of this
interface is to make the communication with other OO-Languages
possible as it is done now for C++.
-- 
------------------------------------------------------------------------
Cyrille Comar,                                  E-mail: comar@cs.nyu.edu
Gnat Project                                    US phone: (212) 998-3489