GDB: varobj support for Ada objects #999

[Joel Brobecker <brobecker at adacore dot com>]

This ticket is to track the overall work need to add support for Ada
objects in the varobj module (GDB/MI variable objects).

Currently, Ada varobj is implemented as a simple wrapper of C varobj.
The initial plan was to simply implement features piecemeal, while
falling back on C varobj for standard or unimplemented constructs.

Unfortunately, I cannot make this work. This is mostly because
the C varobj callbacks implementation needs access to the varobj
as well as the varobj's value.

One situation where this isn't going to work for Ada is the case
where the varobj is an aggregate with one if its fields being
a wrapper (this happens when the field encodes the variant section
of a variant record). For instance, consider the following variant
record:

   type Variant (Disc : Boolean := True) is
   record
      A : Integer;
      case Disc is
         when True =>
            Yes : Boolean;
            No : Boolean;
         when False =>
            D : Integer;
      end case;
   end record;

After evalution, a variable of this type could look like (C-like
syntax used on purpose to be closer to machine representation,
including the casing used for the field names):

    struct variant {
      boolean disc;
      integer a;
      struct {
        boolean yes;
        boolean no;
      } S;
    }

In this case, varobj should be told that this struct has 4 children
(fields), not 3. In other words, the Ada varobj callbacks should
unwrap field "S" on the fly. Similary, when varobj asks for the value
of field #3 (boolean no), it is equivalent to saying we want field #0
of field "S". Since field #0 could itself be a complex type, including
a wrapper, what we want to do in this situation is recurse. But as soon
as we get field #0, we end up with a new value, which does not have
an associated varobj. And as a result, we no longer have enough to
call the C varobj routines.

We should be able to get everything working purely with values.
That's the good news. But the bad news is that we cannot fall back
on the C varobj callbacks, and must implement everything from
scratch. It also means that I cannot commit to our wavefront GDB
until I get results at least as "good" as they are now.

Hence this umbrella ticket.

Individual tickets for each new testcase should be created nonetheless.
I think we are going to need a lot of them.

Assigned to me, priority P.
Deadline: March 1st, 2012.

-- 
Joel