This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
PROPOSAL: out-of-line package initialization
- To: dwarf2 at corp dot sgi dot com (dwarf2)
- Subject: PROPOSAL: out-of-line package initialization
- From: todd dot allen at ccur dot com (Todd Allen)
- Date: Thu, 1 Mar 2001 08:07:43 -0700 (MST)
- Reply-To: todd dot allen at ccur dot com (Todd Allen)
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).
--
Todd Allen
Concurrent Computer Corporation