[commit/Ada] GDB crash printing tagged type variable

[Joel Brobecker]

One of my coworkers reported that the debugger crashes when trying
to print his local variable "X" in the following program:

    with Ada.Strings.Unbounded;
    procedure Main is
       X : Ada.Strings.Unbounded.Unbounded_String;
    begin
       null;
    end Main;

The problem was that GDB was attempting to determine the real type
of our variable by using its tag (this is the data that allows us
to tell the real type of our variable).  The algorithm is slightly
complex but needs to have type Ada.Tags.Type_Specific_Data defined in
the debugging info. This is the case as soon as one unit defining
a tagged type is compiled with debugging info [1].

The reason for inspecting the tag is to handle cases where the
actual type for our variable is dynamic. Consider for instance:

    X : Object'Class := New_Object;

In that case, the debugging information says that variable X is
an obscure unnamed structure whose fields are "_parent" and "C9b".
If we followed this definition blindly, we would get:

    (gdb) p x
    $2 = (x => 0, y => 0, C9b => ())

So, in our case, the debug info was missing, and GDB wasn't prepared
to handle that. This is what this patch does: If we don't find
sufficient debugging information, then use the static information
that we have.  In the case reported by my coworker, this is going
to be sufficient, because the variable type is statically known.

Unfortunately, this is not sufficient in the case where the type
is NOT statically known. We tried to come up with a number of
strategies to be able to retrieve the type name without using
the debugging info, but we eventually concluded that this was
a lost cause, and gave up.

We think that, in practice, the majority of users who use tagged
types will define at least one tagged type in their application,
and that'll be enough to avoid the issue. In the meantime, we do
our best, and no longer crash.

2009-03-12  Joel Brobecker  <brobecker@adacore.com>

        * ada-lang.c (ada_evaluate_subexp) [OP_VAR_VALUE]: For tagged
        types, if we are unable to determine the actual symbol type
        from its tag, then use the static approximation instead.

Tested on amd64-linux. Checked in.

-- 
Joel

[1]: This is because the expanded code associated to the definition
     of a tagged type contains a reference to that Type_Specific_Data
     type, and thus causes it to be included in the debugging info for
     that unit.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 05-print-tagged-type.diff
Type: text/x-diff
Size: 1647 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20090313/60314e37/attachment.bin>