Re: Ada example in Figure 53 [resend]

[brender at gemgrp dot zko dot dec dot com (Ron 603-884-2088)]

Apologies if this is a duplicate. I got the original copy to
dwarf2@corp.sgi.com copy back from postmaster@yog-sothoth.sgi.com with a
"554 Local configuration error" message, so I am resending. (Todd Allen
obviously got his direct copy OK because he has already replied to it...)

From:	brender  7-MAR-2001 11:29:03.69
To:	SMTP%"todd.allen@ccur.com"
CC:	DWARF2-WG,BRENDER
Subj:	Re: Ada example in Figure 53


>Subject: Ada example in Figure 53

I assume you must mean Figure 48 (page 175 in Draft 5)? 

>I thought I should mention that we deviate in a significant way from the Ada
>example that you put in Figure 53.  For a rec2 declaration like this (with
>supporting declarations):
>
>   subtype teeny is integer range 1 .. 100;
>   type arr is array (integer range <>) of integer;
>   type rec2 (n : teeny) is
>      record
>         vec2 : arr(1 .. n);
>      end record;
>
>we do not describe the bounds of vec in a way that is accessible given only
>the address of vec.

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.

>If we did, trouble would arise with our implementation of a record like this:
>
>   subtype teeny is integer range 1 .. 100;
>   type arr is array (integer range <>) of integer;
>   type rec (n : teeny) is
>      record
>         vec1 : arr(1 .. n);
>         vec2 : arr(1 .. n);
>      end record;
>
>The offset of the elements in vec2 simply cannot be known statically
>without knowing the value of the discriminant n.  The way our compilers lays
>out a record like this is as follows:
>
>            +------------------------+
>   word 0   | n                      |
>            +------------------------+
>   word 1   | dynamic offset to vec1 | offset from here to ---\
>            +------------------------+                        |
>   word 2   | dope vector for vec1   |                        |
>   word 3   |                        |                        |
>   word 4   |                        |                        |
>   word 5   |                        |                        |
>            +------------------------+                        |
>   word 6   | dynamic offset to vec2 | offset from here to ---|---\
>            +------------------------+                        |   |
>   word 7   | dope vector for vec2   |                        |   |
>   word 8   |                        |                        |   |
>   word 9   |                        |                        |   |
>   word 10  |                        |                        |   |
>            +------------------------+                        |   |
>   word 11  | vec1(1 .. n)           |<-----------------------/   |
>    ...     |                        |                            |
>   word ?   |                        |                            |
>            +------------------------+                            |
>   word ?+1 | vec2(1 .. n)           |<---------------------------/
>    ...     |                        |
>   word ??  |                        |
>            +------------------------+
>
>The locations of the dynamic offset fields are known statically, but they're
>one level of "indirection" too shallow.  (Actually, it's a squirrelly
>indirection based on an offset from the current address.)
>
>The location description for vec2 looks like this:
>
>   DW_OP_plus_uconst 24
>   DW_OP_dup
>   DW_OP_deref
>   DW_OP_plus
>
>Once you arrive at the offset for vec2, you can't get back to n.  You just
>don't know the offset any more because there's this variable-length vec1
>between vec2 and n.

I will note in passing that Digital Ada (for Ada 83) did not make use
of any "hidden components" such as you describe. This was based in part
on our belief that the language design intended to make hidden components
unnecesary, although there is certainly nothing to preclude them. In this
approach, the calculation of the offset for vec2 would effectively include
calculation of the size of vec1.

>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...)

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?

>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.

>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.

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.)

>Regardless, I'm disinclined to change our implementation of this, because we
>have so many consumers that understand it already.  That even includes one
>that one of our customers wrote, and I'm really loathe to change things too
>radically out from under them, when this solution really does work, and isn't
>even precluded by DWARF 2.0.0.

As before, if what you were doing before is valid DWARF then there is no
reason to abandon it (unless you think V2.1 offers a "better" scheme in
some sense, in which case you might choose to add a newer approach as well
as continuting to support the old).

>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?

Ron
================== RFC 822 Headers ==================
Date: Wed, 7 Mar 2001 10:42:20 -0500
Message-Id: <01030710422014@gemevn.zko.dec.com>
From: brender@gemevn.zko.dec.com (Ron 603-884-2088)
To: todd.allen@ccur.com, DWARF2@corp.sgi.com, BRENDER@gemevn.zko.dec.com
Subject: Re: Ada example in Figure 53
X-VMS-To: SMTP%"todd.allen@ccur.com"
X-VMS-Cc: DWARF2-WG,BRENDER