[RFA/DWARF] Add DW_AT_GNAT_descriptive_type support

[Joel Brobecker]

Thanks for the detailed review, Tom.

> Joel>   (a) You'll see that I put a FIXME after modifying the
> Joel>   TYPE_CPLUS_SPECIFIC macro.  The comment says it all.  I think
> Joel>   that the fix is fine; in fact, we could generalize this approach
> Joel>   to all the accessor macros for the type-specific union - I
> Joel>   wouldn't see a problem with that, and would make the code more
> Joel>   resilient to incorrect field access.  For now, I opted for just
> Joel>   fixing this one macro, since C is usually the "universal" "bare"
> Joel>   language.  Ada or C++ might be less so: Who would want to use
> Joel>   C++ or Ada to display a Fortran array? :-)
> 
> The modified macro uses the default if Gnat aux info is available.  It
> seem to me that the check should instead be to see if the C++ info is
> not available.

Good point. This is a bit of the past coming back at us, where the
initial implementation had no discriminant, just a crude way of checking
whether the type had some gnat-stuff or not.  I have change it to
test for !HAVE_CPLUS_STRUCT.

> Joel>   (b) We need to determine how GCC will tell GDB that it uses the
> Joel>   DW_AT_GNAT_descriptive_type attribute.
> [...]
> Joel>       What's the best way for GCC to tell GDB? At AdaCore, we relied
> Joel>       on a hack, where we parsed a special marker in the CU producer
> Joel>       attribute.  It's kind of gross, but it served us well.  Any
> Joel>       suggestion?
>       
> How about a new GNU extension attribute in the CU DIE?

I think it's a brilliant idea. I'll pass it on to Eric for discussion
with the GCC guys. Thanks!

> Joel> +  if (! HAVE_CPLUS_STRUCT (type))
> Joel> +    n_base_classes = 0;
> Joel> +  else
> Joel> +    n_base_classes = TYPE_N_BASECLASSES (type);
> 
> This seems a little weird to me.
> Do we need this everywhere we use TYPE_N_BASECLASSES?

Yes, but at the same no. Another really good catch.  Yes, because
if the types does not HAVE_CPLUS_STRUCT, then you can technically
not request its TYPE_N_BASECLASSES. However, thanks to the change
above where TYPE_CPLUS_SPECIFIC returns the default cplus-stuff,
and because TYPE_N_BASECLASSES uses TYPE_CPLUS_SPECIFIC to access
the cplus-stuff, TYPE_N_BASECLASSES returns the n_baseclasses value
from the default-cplus stuff, which is zero.

So, I simply removed those changes from the diff.

Here is a new version of the patch.  I only made the two changes above.
Perhaps I should also add a comment besides TYPE_N_BASECLASSES to explain
that it returns 0 if !HAVE_CPLUS_STRUCT, but I think it's fine as it is
now, given the specific comment besides TYPE_CPLUS_SPECIFIC.

gdb/ChangeLog:

        Add support for DW_AT_GNAT_descriptive_type.
        * gdbtypes.h (enum type_specific_kind): New enum.
        (struct main_type) [type_specific_field]: New component.
        [type_specific]: Add new component "gnat_stuff".
        (struct gnat_aux_type): New type.
        (INIT_CPLUS_SPECIFIC): Also set TYPE_SPECIFIC_FIELD (type).
        (HAVE_CPLUS_STRUCT): Also check TYPE_SPECIFIC_FIELD (type).
        (gnat_aux_default, allocate_gnat_aux_type): Add declaration.
        (INIT_GNAT_SPECIFIC, ALLOCATE_GNAT_AUX_TYPE, HAVE_GNAT_AUX_INFO)
        (TYPE_SPECIFIC_FIELD): New macros.
        (TYPE_CPLUS_SPECIFIC): Return cplus_struct_default if the given
        type does not hold any cplus-specific data.
        (TYPE_RAW_CPLUS_SPECIFIC): New macro.
        (TYPE_GNAT_SPECIFIC, TYPE_DESCRIPTIVE_TYPE): New macros.
        (TYPE_IS_OPAQUE): Use HAVE_CPLUS_STRUCT to check if type has
        cplus-specific data.
        * gdbtypes.c (allocate_cplus_struct_type): Minor stylistic rewrite.
        Set new component TYPE_SPECIFIC_FIELD (type).
        (gnat_aux_default): New constant.
        (allocate_gnat_aux_type): New function.
        (init_type): Add initialization the type-specific stuff for
        TYPE_CODE_FLT and TYPE_CODE_FUNC types.
        (print_gnat_stuff): New function.
        (recursive_dump_type): Use HAVE_CPLUS_STRUCT to check for cplus-
        specific data.  Adjust code that prints the contents of the
        type-specific union using the TYPE_SPECIFIC_FIELD value.
        * dwarf2read.c (dwarf2_attach_fields_to_type): Do not allocate
        the type cplus stuff for Ada types.
        (dwarf2_add_member_fn, dwarf2_attach_fn_fields_to_type):
        Error out if these routines are called with an Ada type.
        (read_structure_type, read_array_type, read_subrange_type):
        Add call to set_descriptive_type.
        (set_die_type): Initialize the gnat-specific data if necessary.
        (need_gnat_info, die_descriptive_type, set_descriptive_type):
        New functions.
        * ada-lang.c (decode_constrained_packed_array_type): Use
        decode_constrained_packed_array_type instead of doing a standard
        lookup to locate a parallel type.
        (find_parallel_type_by_descriptive_type): New function.
        (ada_find_parallel_type_with_name): New function.
        (ada_find_parallel_type): Reimplement using
        ada_find_parallel_type_with_name.
        * ada-valprint.c (print_field_values): Use HAVE_CPLUS_STRUCT
        to check if type has a cplus stuff.
        * linespec.c (total_number_of_methods): Likewise.
        * mdebugread.c (new_type): Likewise.

gdb/testsuite/ChangeLog:

        * gdb.base/maint.exp: Adjust the expected output for the
        "maint print type" test. Use gdb_test_multiple instead of
        gdb_sent/gdb_expect.

Tested on x86_64-linux. No regression, just one expected change.
I think this addresses both of Tom's comments, but I'm going to wait
a little for confirmation and/or last second objections.

-- 
Joel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: at-descriptive-type.diff
Type: text/x-diff
Size: 28921 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20100111/8b9a48c3/attachment.bin>