Re: DW_AT_base_types

[Michael Eager <eager at eagercon dot com>]

Ron 603-884-2088 wrote:
> 
> 
> 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?

No.  If anything, the text suggests that the base types are declared in
the referenced CU but not in the current CU.

There does not appear to be any assurance that all types are declared 
in the referenced CU.  This might be a reasonable use, but not guaranteed.

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

Presumably, only the highest level entries are referenced.  They are 
not scoped within any function or structure.

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

Also at global level.

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

Base types without a name would seem problematic.  How would you look
for the base type you want without the name?  (Section 5.1 says that a
base type is declared with a name.)

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

Presumably, if you have a definition of a base type in the current CU, 
then you have no reason to look at any CU referenced by an DW_AT_base_types
entry.  There is an implied scoping here:  the DW_AT_base_types is only 
used if the base type reference cannot be resolved.

I don't know of any implementation which uses DW_AT_base_types.  It was 
proposed to solve a problem which, it appears, no one really finds all
that pressing.  This makes discussion of what and how it really works or
should work a bit vague.

-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077