[Gnat] Finding exceptions without gdb

[Gnat] Finding exceptions without gdb

[Bob Collins]

Is there any way to find out where (in source) exceptions
are raised without using gdb? (And without Put-ting the
information in excception handlers.)

Re: [Gnat] Finding exceptions without gdb

[Robert Dewar]

Bob Collins asks

"Is there any way to find out where (in source) exceptions
are raised without using gdb? (And without Put-ting the
information in excception handlers.)"

No, you need to use gdb to get the traceback to find out where an exception
occured (exept on the VMS version, where the system provides traceback
facilities). We assume incidentally you are talking about GNAT (Remember
to say so, it is not always easy to guess!)

Note that gdb is completely non-intrusive, it does not affect your program
in any way up to the point where a breakpoint is hit, so one thing you
can do is to set up scripts that routinely run udner control of gdb (Mike
Feldman does this for his students).

Incidentally, it is not a matter of philosophy that you have to use the
debugger to get tracebacks, just a mmatter of practicality. Providing
traceback capability for a given architecture is hard work, but possible,
as you see in several compilers, but providing it in a target independent
manner is extremely difficult. One of the disadvantages of the GCC approach
is that since it is so incredibly portable (and ported to hundreds of
targets), in order to maintain this portablity, we have to be very wary
of target dependent code.

Eventually we hope to see a general solution to this (the problem is related
to the issue of general exception handling). Meanwhile, using gdb to solve the
problem is easier than you might think, given the guarantee that it is a
non-intrusive debugger, and of course, once you are in gdb you have more
capability than just getting a traceback.

Re: [Gnat] Finding exceptions without gdb

[Stephen Leake]

As has been pointed out many times, there is full documentation on how
to use gnat, including how to use gdb with gnat compiled code, in the
gnat documentation, specifically the file doc/gnatinfo.txt. Yes, this is
a flat text file; that's what "search" commands in text editors are for!

Searching for "gdb" and then "exceptions", we find:

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

Happy debugging!
-- 
- Stephe

Re: [Gnat] Finding exceptions without gdb

[Kevin Rigotti DRA]

Stephen Leake wrote:

> Exceptions can be caught by breaking in the "__gnat_raise" routine and
> then doing a "bt" or "where" command.
If your code uses exceptions for non-fatal "error" handling, such
as 'file not found' when opening log files, then __gnat_raise gets
called rather too often to be useful.

If the exception is one you define yourself then it is worth wrapping
it in a procedure call. That way you can set a breakpoint on the
wrapper and get a stack back-trace, plus whatever diagnostics you
choose to put in the wrapper.

Just my $0.02

Kevin

Re: [Gnat] Finding exceptions without gdb

[Stephen Leake]

Bob Collins wrote:
> 
> Is there any way to find out where (in source) exceptions
> are raised without using gdb? (And without Put-ting the
> information in excception handlers.)

Ooops, sorry for my last post. It's early, and I read the request as
"how do I find exceptions USING gdb", but the question is "WITHOUT using
gdb". Sigh.

The only way I know to identify the point an exception is raised is to
se gdb to catch it. An approximate location can be found by putting
exception handlers in EVERY block, and putting a message to a screen, or
passing a string in a re-raised exception. You have ruled out both
options.

Why have you ruled these out?
-- 
- Stephe