Comments on draft 1 revisted

[davea at quasar dot engr dot sgi dot com (David B Anderson)]

|>==== 3.1 Compilation Unit Entries page 30
|>The description DW_AT_base_types is still not clear.
|>
|>It's useful for interpreting a conversion to a base type 
|>when that base type is not mentioned in a current compilation
|>unit, as then there is no reference chain for a debugger to follow,
|>so a commonized list of base types  off in some
|>other compilation unit might help.
|>
|>It's also not clear (any more than in the original document)
|>what DIE type this might point to. CU die? Something else?
|>Did we ever decide this for the original document?
|>Am I just missing something here?
|
|PENDING -- I don't adequately understand your concern...

Well, maybe it's not really worth considering...
I'll try to explain.

Consider the following 3 cases:

case 1.
CU (compilation unit) 1 
has object foo1 with a type attribute of a base type int 
(32 bits, signed)
in CU 1.

case 2.
CU 2 has  an object foo2 with a type attibute DW_AT_type
with DW_FORM_ref_addr referring to
CU 6, and CU 6 has a DIE (referred to from
the CU 2 DIE of foo2) of base type int.

case 3.
CU 3 has no base type int, but has
DW_AT_base_types, which is a reference to CU 4 where
CU4 has base type int in it somewhere.

Case 1 is clear: no DW_AT_base_types is needed to find
the base type 'int'.

case 3 is clear: DW_AT_base_types might be useful
to find the base type 'int'.

case2: 
case 2 (CU 2) has no definition of base
type int, (as defined in 3.1) but *also* has no use for
DW_AT_base_types to access base type int! (because it has the
specific reference to another CU).  case 2 seems
to leave the reader with an question as to the 
need for DW_AT_base_types.   Is DW_AT_base_types needed
to access 'int'?  But it is duplicating another reference...

SUMMARY: in case 2, the DW_AT_base_types is
unnecessary to access type 'int'. Not harmful,
just useless for 'int'.   But it's hard to tell
from the description that it's not needed.
Which, IMO, makes the description unclear as written.
Much reasoning for the reader
to figure out such a simple thing we
already know (that in case 2, DW_AT_base_types is not
really useful/necessary for 'int')...

Beating the poor dead horse some more, 
the 'compilation unit that does not contain such
definitions' is the phrase which leads to 
confusion.


[ ]
|>==== 6.2.4 statement program prologe page 69
|>
|>This is (I think) the
|>first appearance of '64-bit safe DWARF' and, like
|>Mike, I think this is the wrong phrase to use.
|>It's not accurate.
|>
|>After pondering for a few minutes, I think that
|>  "extended-section-offset DWARF"
|>would be a better description.
|>(not perfect, but better)
|>
|>The phrase appears many places of course.
|
|PENDING -- part of 000403.2 discussion. How do
|
|    32-bit DWARF format
|and
|    64-bit DWARF format
|
|grab ya for the original and our/your extension?
|


It's fine.


[ ]
|>==== Appendix 6 Aggregate examples, page 156
|>
|>Just before the paragraph beginning "The F90 derived type array_ptr"
|>I suggest adding a paragraph:
|>
|>"If an object has a descriptor, then the dwarf type for the object
|>will have the DW_AT_data_location attribute. If an object
|>does not have a descriptor, then the dwarf type for the object
|>will not have the DW_AT_data_location attribute."
|>
|>This is to reinforce what I think Ron means...
|
|YES (almost)
|
|>==== Appendix 6 Aggregate examples, page 156
|>
|>Change
|>	"fixed compiletime known size"
|>to
|>	"fixed compile time size"
|>, IMO.
|
|YES
|
|>Note that the "desc<1>" sentence that this refers to is
|>one that I had to stare at quite a while before I began
|>to understand it.  It could just be me or it could be
|>that this needs some rephrasing or elaboration?
|
|PENDING -- seems OK to me, and I have yet to think of an
|alternative I like... Is it just a matter of defining before
|use, rather than versa-vica?


It's that desc<1> is inventing a terminology.
It means (I think) that
	desc<1> ap
says "ap is a pointer to a
struct desc descriptor object 
with num_dims==1 in that descriptor object"
(which you already explained is not a struct
that the debugger user would see).

But the reader has to figure this out. There is
no 'definition' of the terminology.

It would be, I think, better to simply give the (a?)
simple definition.
Have I got it right?
Perhaps there is a better way to put this?


[ ]
|>==== Appendix 6 Aggregate examples, page 157, etc
|>
|>I think the TAGS should be slightly indented where
|>appropriate to indicate child (vs sibling) relationship.
|>The existing layout obscures this essential feature of
|>DW_TAG_subrange_type, for example.
|
|YES (but I wasn't sure specifically which you were concerned about,
|so do doublecheck that my fixes got what you saw)

I meant 2$ indented under 1$

4$ and 5$ indented under 3$

The rest was indented ok, I think. Just those 3 lines
failed to show child status by indenting.


Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/