Re: Comments on draft 1 revisted

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

Dave,

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

Ah, now I understand your confusion -- indeed, you have
helped me become confused too!

The real question is just what does this attribute 'do'?

Questions:

  - Is the DW_AT_base_types attribute a short hand way of saying
    that "all of the base types 'declared' in the given compilation
    unit are also "declared" in this one? 

  - What set of base types in the given unit are referred to?
    Only those declared "at module level" (direct children of the
    DW_TAG_compilation_unit entry)? Any base type declared anywhere
    in the given unit?

  - Where do the implicit declarations occur in this (the containing)
    unit? At module level? (I can't think of an alternative.)

  - Does it matter whether or not a base type in the given other
    unit has a name or not?

  - What if one (or more) of the base types in the given unit has a
    name that conflicts with a name (base type or not) declared in this
    unit? Is a redundant declaration (same name, same encoding) different
    than any other case?

Perhaps one of the participants from the DWARF V2 committee can help explain
just what is intended here? (Maybe I am not even on the right horse, dead or
otherwise...)


>|>==== Appendix 6 Aggregate examples, page 156
>...
>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?

OK, now I understand. I made some changes that hopefully
will help.


>|>==== Appendix 6 Aggregate examples, page 157, etc
>|>...
>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.

YES, I believe these are fixed.