[PING*4] add support for dwarf AT_GNU_descriptive_type

Joel Brobecker brobecker@adacore.com
Wed Nov 10 05:55:00 GMT 2010


> Yes.  If there is a better way to describe the source
> using existing DWARF constructs, I'd like to be able
> to recommend it.  If there is a need for an enhancement
> or extension to describe Ada better, I'm interested.

What we are trying to say, here, is that this patch is not related
to that objective.  We already know how to properly describe most
of the entities used in Ada. We hope to get to that, one day, but
it's a big project, and I don't see that happening for a while.

So, instead, we're stuck with the GNAT encoding (which is documented
in exp_dbug.ads).  The GNAT encoding has the good property of working
regardless of the debugging format - in other words, it can work even
with STABS.  Like it or not, we are still stuck with stabs on some
platforms.

In any case, the GNAT encoding is designed mostly around parallel
types - and I will give an example later if that helps understand
things.  What that means is that the compiler creates artificial
types that help us convey semantic information about other types.
The downside of this approach is that it requires the debugger to
search, by name, for those parallel types. On large applications,
this can be expensive.

Example:  Consider for instance the following array whose upper bound
is dynamic:

        type My_Array is array (1 .. Upper_Bound) of Integer;

With STABS, you can't express the value of the upper bound as
a dynamic value.  So the compiler generates a parallel type,
named my_array___XA which helps us determine the bounds. In
particular, the XA type will tell us, through a mechanism
that I won't bore you with but is documented in exp_dbug.ads
that the upper bound is dynamic, and that its value is to be
found by getting the value of Upper_Bound.

So the issue, when trying to print an object of type My_Array,
is to find that ___XA type in order to find the value of the
upper bound.  With STABS, we're stuck, we have to do the lookup.
But with DWARF, we've been using an extension, an attribute,
that links type My_Array directly to its associated ___XA type.
Getting to the ___XA type becomes instantaneous.

That's what we're talking about here: A performance improvement
that allows the debugger to quickly find the required parallel
type, instead of doing the expensive global lookup.  The fact
that it is tied to DWARF right now is only an implementation
detail.  If we could do the same with STABS, we'd no doubt do it
too.

I realize that this is not ideal.  We should be generating perfect
DWARF. But we don't. And we won't, at least for a while.  In the
meantime, let's make it easier for the Ada fans out there, to debug
their Ada code.  Before I joined AdaCore, I used to depend on their
yearly public releases to get improvements. It was 10 years go, but
I haven't forgotten about that time. Although I believe the situation
is a hundred times better today, particularly in terms of code generation,
we still have ways to go in terms of debugging Ada.

I hope that convinces helps you understand the context and convince
you that this should never affect the DWARF standard. And I hope
that this shows that this change will provide immediate positive
improvements at virtually no cost to the compiler.

-- 
Joel



More information about the Gcc-patches mailing list