Re: [PATCH] gdb.ada/catch_ex.exp, gdb.ada/mi_catch_ex.exp and unsupported catchpoints

[Joel Brobecker <brobecker at adacore dot com>]

> Here's a start.  I didn't really try to confirm if I was extracting the
> arguments correctly for any other function bug the Ada runtime's
> function in question, but at least it works in the case we're
> interested in.  :-)

Not bad :). On the other hand, I'm wondering if this is really worth
the effort.  With a stripped libgnat, this is not the worse problem
you are ever going to face.

I think a much worse problem is the fact that you are not going to be
able to print the value of what we call tagged types (aka classes in
C++).  For GDB to decode a tagged variable, it needs to find know how
ada__tags__type_specific_data is defined.  Tagged variables unfortunately
do not reference this type directly, which means that a unit using
tagged variables/types will NOT contain a description of that type.
So, the only unit that contains that data is usually Ada.Tags
(a-tags.ad[sb]). This is why stripping lignat also breaks that feature.

I think that the long term plan would be for the compiler to describe
our tagged variables using an adequate DWARF description, yet to be
determined.

Back to the problem with exceptions, I just checked in a series of
patches that cleanup a bit the support for exceptions. One of the
improvements brings a check for stripped runtimes, and a better
error message when we detect this situation:

    (gdb) catch exception
    Your Ada runtime appears to be missing some debugging information.
    Cannot insert Ada exception catchpoint in this configuration.

That should help a user understand better what's going on.  Perhaps
one last step to help him figure out what to do next is to expand
the documentation about the catch exception command a bit.

> Unfortunately, libgnat is fully stripped (at least on ubuntu), symbol
> table and all,

That reaffirms my belief that it's a battle not worth fighting. Better
to help the users figure out what's going on and how to fix it rather
than trying to support this setup.

-- 
Joel