[Wow, that's an even longer email that I thought it would be, but
I thought it would be better to provide more explanations to help
with the reading of the patch]

Hello,

As previously mentioned, I would liket to add support for a GNAT-specific
DWARF attribute, which we introduced to help with performance when
debugging Ada.

Quick summary: The debugging info for Ada code follows an encoding
(document in exp_dbug.ads in the GCC sources) which requires
"parallel lookups". For instance, a record type with variable-size
fields will see a parallel type named type___XVE being generated
by the compiler.  The debugger is supposed to look this type up
in order to obtain some info necessary to decode the type.

The new DW_AT_GNAT_descriptive_type attribute allows us to speed up
this lookup when using DWARF, as this attribute is used to point to
the DIE of the corresponding parallel type (there is always only one,
or else they are chained in the logical order).

I have taken the time to order the patches to follow the same order
as if I was to write the patch all over again (gdbtypes updates,
dwarf2read updates, etc).  Hopefully this will help reading it.
Roughly, the patch contains the following changes:

  1. The introduction of an enumerated type, used as a discriminant
     for the type_specific union (enum type_specific_kind).

  2. The introduction of a new field in the type_specific union
     to store the "gnat_stuff", with various new macros and routines.

  3. dwarf2read updates to use that attribute (along with some
     adjustments due to the gdbtypes updates).

  4. ada-lang.c updates to use the descriptive type if the compiler
     emits it.  Otherwise, we fallback on the traditional method of
     doing a global lookup by name (still needed in the case of stabs).

  5. Some minor adjustsments due to the gdbtypes updates.

I think that this patch, in addition giving us enhanced performance
for Ada, also brings an interesting cleanup in the way we handle
the type_specific data.  It's still messy, IMO, but a little better,
as we no longer have to guess what kind of type-specific data we have.
This will also be useful in the context of gdb-gdb.py, our future
gdb types pretty-printer.

There are still a couple of things that are worth discussing:

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

  (b) We need to determine how GCC will tell GDB that it uses the
      DW_AT_GNAT_descriptive_type attribute.  This is important to know,
      because the absence is used as meaning that there is for sure
      no parallel type (and thus, we do not search any).

      You'll see that the patch that I am submitting today has a function
      dwarf2read.c:need_gnat_info() which returns true for all Ada units.
      This is fine for AdaCore's GDB, where our version of the compiler
      has been generating this attribute for years.   But we need something
      more refined for the FSF version, since the FSF GCC does not emit
      this attribute yet.

      What's the best way for GCC to tell GDB? At AdaCore, we relied
      on a hack, where we parsed a special marker in the CU producer
      attribute.  It's kind of gross, but it served us well.  Any
      suggestion?
      
      In the meantime, what I propose is the following: The version that
      I check in will always return false for now.  Once this patch is
      checked in, I will task Eric Botcazou, our debug info generation
      guru to contribute the code that generates this attribute - and
      I will ask him, at the same time, to discuss of an acceptable way
      for the compiler to pass that information.  Once agreed upon,
      I will implement the GDB side.  Would that be acceptable?

The patch was written by Paul Hilfinger, and then later updated by me
(mostly adding the new discriminant, and cleaning things up accordingly).

Tested on x86_64-linux with no regression. Comments? OK to commit?
There is no NEWS entry yet, as the feature (performance improvement)
is not going to be available until the corresponding change is in GCC.
I will need to update need_gnat_info to activate the feature anyway,
so I will provide the NEWS entry then.

One last thing: The include/dwarf2.h patch has also been sent to GCC
for approval....  Except that I just realized that it seems to be
maintained by binutils! Ooops, will fix.

Thanks,
-- 
Joel