Re: Ada example in Figure 53

[todd dot allen at ccur dot com (Todd Allen)]

> 
> >Subject: Ada example in Figure 53
> 
> I assume you must mean Figure 48 (page 175 in Draft 5)? 
> 

Apparently so.  I've been working from the dif-base copy, and I guess the
numbers of its Figures are skewed.  I guess its time to print a copy of the
non-dif version.

> 
> There is no intention to imply that this example shows the *only* way to
> describe something. It (and all examples) are intended to show that there
> is at least one way, as well as to motivate the presence of certain DWARF
> features/mechanisms.
> 

I see that section 1.2 indicates that only sections 1 through 6 contain
informational content.  I assume that means they are the only sections that
are binding.  (Or, as we say in Ada when we're wearing our language lawyer
hats, "normative".)  BTW, I'm surprised that section 7 isn't included.  Is it
the intent that it be only "strongly suggested"?

How about a little bit of text to that section explicitly stating that
section 7 and the Appendices are non-binding?

> 
> >So, our approach was to describe the bounds of the array types for vec1 and
> >vec2 so that they referenced the DW_TAG_member entry for "n".  This does
> >require the debugger to keep its wits about itself, and remember the context
> >in which these members are declared.
> 
> I'm losing context here. By the "array types" for vec1 and vec2 I assume
> you are referring to the DWARF array types that corresponds to the Ada
> subtypes for vec1 and vec2 (because DWARF does not have a type/subtype
> distinction). The Ada type arr certainly cannot reasonably refer to the
> member n, right? (But see below...)
> 

Actually, we did augment DWARF so that it can differentiate between entirely
new types like "type int is range 1 .. 100", derived types like "type int is
new integer range 1 .. 100", subtypes like "subtype int is integer range 1
.. 100".  Also, we describe interesting subtype_indications as additional
anonymous subtypes.  I don't think that's important to the discussion, but
I'll toss it out there anyway.

Getting back on track: Right.  The array type for "arr" can't indicate the
discriminant "n".  (There might be other objects, subtype, derivations,
etc. that use it and which don't use "n" as a bound.)  What I should have
said was that we describe an anonymous subtype for the components vec1 and
vec2 and the bounds of the anonymous subtype's array bounds are the constant
1 and the discriminant "n".  I think you worked that out, based on later
comments.

>
> Your suggestion that the debugger must "keep its wits about itself" does
> make me a tad uncomfortable because it suggests it must do something that
> may be surprizing. For example, are you comfortable that *any* good
> DWARF based debugger would keep the right wits?
> 

Well, probably not.  If the debugger had only ever seen C/C++ code, then it
certainly wouldn't have encountered anything like this before.  I'm sure it
would need to be trained.  But it was our experience that training our
debugger to keep its wits in this case wasn't all that hard.

Note that this probably won't be the only place where a debugger that has
only ever consumed nice bland C/C++ debug info will have to be trained to
cope with Ada DWARF, though.  Almost certainly, there will be lots of
simplifying assumptions that they'll have made for C/C++, and the assumptions
just won't hold for Ada.  (That, too, was our experience with our debugger.)

> >But I can't see anything that disallows this sort of thing in DWARF spec,
> >other than the new notes after Figure 52.
> 
> You mean Figure 49? If so, those notes are simply observations about the
> example shown and don't/can't disallow anything.
> 

Yes.

> >I suppose we could support this example in DWARF 2.1 differently by making
> >the type of the vec1 and vec2 components be a new anonymous array type (and
> >indicating that it was subtyped from the proper one), and putting a
> >DW_AT_data_location on the type to do the final dup/deref/plus operation, and
> >then omitting that in the location descriptions for vec1 and vec2.  It seems
> >like a bit of a perversion, because the arrays really don't have the hidden
> >levels of indirection; the record does.  But I think it would make everything
> >work.  In this example, at least.  I'd have to think long and hard about
> >whether or not I could dream up a more horrible example for which it wouldn't
> >work.  (Oh, if only I'd saved all the horrible examples I dreamed up when I
> >was coding the Ada DWARF emitter...)
> 
> Hmmm... now I am confused. I thought such anonymous array types were exactly
> what you were talking about earlier -- the ones that refer to n. I am getting
> very confused.
> 

In the earlier example, there was a subtype.  I'm talking about replacing it
with a different one that "backs off" a level of indirection so that the
bounds remain a known distance from the "backed off" location, and then uses
DW_AT_data_location to restore the extra level of indirection.

>
> Perhaps if you supply some kind of dump of the your actual DWARF for this
> example, it would clarify things? (Among other things, how the so-called
> "dope vectors" fit in is opaque to me at the moment.)
> 

I think the issue is resolved to our satisfaction, but if you like, I'll
send a DWARF dump along in a subsequent mail, for the curious.

> 
> >BTW, although the intent of the Ada example in Figure 53 is clear, the code
> >isn't legal Ada.  My first example in this mail is a legal version of it.
> 
> Again, Figure 48?
> 
> OK, you sent me back to my Ada Manual. The DWARF spec certainly is intended
> to use legal examples!
> 
> One correction I see is that the discriminant subtype can only be a
> typemark. That change is easy to make. You also rewrote the anonymous
> array to be explicit (which I overlooked when my Ada manual as in hand)
> -- I assume that is also necessary, yes?
> 

Yes, on both counts.  You must be looking at an Ada 83 manual.  (I've almost
completely forgotten the Ada 83 terminology.  Almost.)  In Ada 95, we'd say
that the discriminant can only have a subtype_mark, not a full-blown
subtype_indication.

As for the anonymous array types, you can't use them for components, only
stand-alone objects.  An object_declaration may have either a
subtype_indication or an array_type_definition.  A component_definition, on
the other hand, can have only a subtype_indication.  So, you have to declare
an unconstrained array type and then constrain it appropriately for each
component.

And then because I'd declared "teeny", I thought it wise to use it in the
declaration of the unconstrained array, because some Ada implementations use
the "allocate the maximum amount of space" approach, and you don't want them
allocating components that are 2^32 words long!  And then, I made M and N
both be of type teeny, too, just for clarity.  It avoids the implicit subtype
conversions from integer to teeny.  (Although maybe only a language lawyer
would care... :) )

-- 
Todd Allen
Concurrent Computer Corporation