Issue 050808.1: Discontiguous scopes
Section: 2.16.3, 4.1
Page: 59
This is a follow-up to issue 030626.1; Chris Quenelle [Chris.Quenelle@Sun.COM]
was too busy to do a write-up, so I volunteered. If I've understood things
correctly, the initial issue was left unresolved and a subsidiary issue was
resolved. Chris was going to design a system which tied the discontiguous
scopes to source locations rather than to machine instructions, but he now
believes that's too open a topic to bring up for V3. I'm not addressing that
issue, but am adressing the initial issue from the 030626.1.
The issue is this: given a variable which has a "live" scope in a source block
that has been itself chopped into a set of discontiguous (and possibly re-ordered
set of instruction blocks), how do we represent the sub-blocks in which the variable
is live, and where does that "liveness" start? I'll note in passing that it might
make semantic sense for the liveness to start and stop more than once, given the
re-ordering.
The current state is this text in 4.1, bullet 11:
If the containing scope is non-contiguous
(see Section 2.16.3), the value of this attribute is
the offset in bytes of the beginning of the scope
for the object from the beginning of the first range
list entry (that is not a base selection entry or an
end of list entry).
[editing note: I'd remove the parentheses around "(that...entry)";
I think they're unneeded.]
This describes an object scope which begins somewhere after the
start of the source code scope's ranges, but which is "live" from that
point to (implicitly) the end of the source code's ranges. This means
it is live even during intervening ranges from other bits of source,
so it's not completely accurate.
However, I believe that text will do for V3, so 030626.1 can stay resolved!
Here is the proposal for V3+, based on the suggestions (e.g. from Jim
Blandy and David Anderson) in topic 030626.1:
Add after the above quote (4.1, bullet 11)
[added text]
If the scope of the object itself is discontiguous, the scope has
more than one start location, or DW_AT_start_scope for some reason
will not correctly represent the scope of the object, the object
entry may instead have a DW_AT_scope_ranges attribute. The value of this
attribute is a rangelist of the ranges in which the object is in scope.
[end added text]
Given that this is a rangelist, we don't need to add text explaining
what the offsets are from: that's already defined.
Given that the object ranges are discontiguous, there's no need to
call out any one of the "starts" as _the_ start, so the two attributes
aren't going to co-occur and we can then make them alternates.
Note that the use of DW_AT_scope_ranges is not restricted to the case
that the enclosing code scope is discontiguous.
Proposal (Ron Brender, 7/8/2007):
1) In Section 2.17, page 32, insert the following just before the
beginning of Section 2.17.1:
"In addition, a non-contiguous range of addresses may also be
specified for the DW_AT_start_scope attribute as described in
Section 2.17.3."
2) In Section 2.17.3, append to the first paragraph:
"Similarly for a DW_AT_start_scope attribute."
3) In Section 4.1, p61, replace the first paragraph of bullet 11, namely
"11. If the scope of an object begins sometime after the low pc
value for the scope most closely enclosing the object, the
object entry may have a DW_AT_start_scope attribute. If the
containing scope is contiguous, the value of this attribute is
the offset in bytes of the beginning of the scope for the
object from the low pc value of the debugging information entry
that defines its scope. If the containing scope is
non-contiguous (see Section 2.17.3), the value of this
attribute is the offset in bytes of the beginning of the scope
for the object from the beginning of the first range list entry
that is not a base selection entry or an end of list entry."
with the following:
"11. If the scope of an object is smaller than (that is, a subset
of the addresses) for the scope most closely enclosing the object,
the object entry may have a DW_AT_start_scope attribute. There are
two cases:
1) If the scope of the object entry includes all of the containing
scope except for a contiguous sequence of bytes at the beginning
of that containing scope, then the scope of the object is
specified using a value of class constant. If the containing
scope is contiguous, the value of this attribute is the offset
in bytes of the beginning of the scope for the object from the
low pc value of the debugging information entry that defines
its scope. If the containing scope is non-contiguous (see
Section 2.17.3), the value of this attribute is the offset in
bytes of the beginning of the scope for the object from the
beginning of the first range list entry that is not a base
selection entry or an end of list entry.
2) Otherwise, the scope of the object is specified using a value
of class rangelistptr. This value indicates the beginning of
a range list (see Section 2.17.3).
*Due to optimization, the scope of an object may be non-
contiguous and require use of a range list even when the containing
scope is contiguous. Conversely, the scope of an object may not
require its own range list even when the containing scope is non-
contiguous.*"
