PURPOSE:

In Ada, frequently packages have associated "elaboration" code, to initialize
objects, to evaluate dynamic expressions in subtype or array bounds in order
to freeze them, to set elaborated flags when needed, etc. We use
DW_TAG_module to describe packages, because they are so similar to Modula's
modules. But we did ignore 3.2.1 with regard to the initialization code.
Instead, we describe it as a separate routine with a DW_AT_artificial
attribute whose value is true.

This allows us to describe the logical nesting relationship of the package,
and the possibly quite distinct nesting relationship of its elaboration
routine, which may be an out-of-line procedure (e.g. for a library package,
or a separate package, among others), or performed in-line as part of another
procedure (e.g. for a simple nested package). In the case where the
procedure was out-of-line, it allowed us to use the preexisting mechanisms
for describing the stack frame, the static link, etc. In the case where the
procedure was in-line, we split its elaboration routine description into
abstract and concrete pieces.

Note that we made no effort to identify the elaboration procedure of a
module, other than to mark it with DW_AT_artificial (which doesn't uniquely
identify it if there are any other artificial routines existing for any other
purposes), and to give it an appropriate name like "foo elaboration routine",
so that it was identified usefully if a user stepped into it or stopped
within it. We considered making a closer association, but threw out the idea
when we couldn't identify any use for that information.

I propose loosening the language in 3.2.1 to allow for this.

WORDING CHANGES:

3.2.1

| If the module contains initialization code, the code may be described in
| one of two ways:
|
|     * The module entry has either a DW_AT_low_pc and DW_AT_high_pc pair of
         attributes or a DW_AT_ranges attribute whose values encode the
         contiguous or non-contiguous address ranges, respectively, of the
         machine instructions generated for the whole module initialization
         code (see Section 2.16). It may also have a DW_AT_entry_pc attribute
         whose value is the address of the first executable instruction of that
         initialization code.
|     * The module entry has a child DW_TAG_subprogram entry that describes
|       an initialization subroutine (see Section 3.3). The DW_TAG_subprogram
|       should contain a DW_AT_artificial attribute whose value is the flag
|       true. This form must be used if the initialization code is an
|       out-of-line subroutine or if it is an in-line subroutine nested within
|       a scope other than the module entry, but is allowed in any case. Note
|       that, if the code is in-line and within the the module entry, then the
|       module entry also will contain a child DW_TAG_inlined_subroutine (see
|       3.3.8.2).

After discussion, it was decided that substantially the same effect could be obtained by changing the wording of section 3.2.1, paragraph 4, to say that a TAG_module may have AT_low_pc and AT_high_pc attributes or AT_ranges, rather than that it must have one of these specified.  This change was adopted.