Issue 030626.1: DW_AT_start_scope and discontiguous scopes
Ron Brender writes:
A colleague has observed that there is a problem in how to intrepret an
DW_AT_start_scope attribute when the containing scope is discontiguous.
Because there is no required ordering for the segments of a discontiguous
scope (in the .debug_loc section), there is no defined sequence of
segments in which to interpret the start_address attribute.
Following is his problem description together with one suggestion for how
to resolve it.
=====================
Bevin Brett writes:
Consider a scope
{
part1
part 2 int a = f();
part3
part4
}
which, for optimization reasons, has been emitted as instructions in the
following address order
part3
...
part2 int a = f();
...
part4
...
part1
The Scope should have DW_AT_ranges as its pc encoding.
But what should "a" have as its DW_AT_start_scope?
I suggest that the committee consider requiring...
(1) The DW_AT_ranges be output in LEXICAL ASCENDING order
(2) The DW_AT_start_scope be the offset from the first range (possibly
negative) or (alternative proposal) from the lowest low_pc
This would enable the debugger to determine that A is visible in the later
half of part2, all of part3 and part4, but not in part1
==================
Jim Blandy writes:
It's a shame that the 'rangelistptr' and 'constant' classes overlap
(both use DW_FORM_data{4,8}). Otherwise, we could simply allow
DW_AT_start_scope to be a range list, instead of a simple offset.
I'd suggest:
- saying that DW_AT_start_scope cannot be used when the enclosing
scope's location is a rangelist, and
- providing an alternative attribute, DW_AT_scope_ranges, whose value
is a rangelist indicating where the object is in scope. Producers
can use this when DW_AT_start_scope cannot be used.
================
David Anderson writes:
Apparently fixing DW_AT_start_scope requires constraining
either range lists or DW_AT_start_scope.
Jim Blandy suggests constraining range lists.
I suggest constraining DW_AT_start_scope.
With my proposal, the optimization causes a loss in precision of
the start-of-range (in this formulation) when the range is
actually split up.
PROPOSAL:
In 2.16.3, add after a new paragraph after the second paragraph,
with contents:
"If a DW_AT_start_scope attribute refers to code described by a
range list with more than as single entry the starting-point
of the scope becomes ambiguous (as it is impossible to tell
from the range list what areas logically preceed or follow the
instruction address in the areas described) so any
DW_AT_start_scope should be ignored (as if DW_AT_start_scope
were not present)."
-----------------------------------------------------------------
Modified:
DW_AT_start_scope is offset from FIRST location in a discontiguous scope.
