DWARF Standard


030626.1 David Anderson DW_AT_start_scope and discontiguous scopes Clarification Accepted with modifications None

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



                        part 2 int a = f();




which, for optimization reasons, has been emitted as instructions in the
following address order



            part2 int a = f();





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.


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)."


DW_AT_start_scope is offset from FIRST location in a discontiguous scope.

All logos and trademarks in this site are property of their respective owner.
The comments are property of their posters, all the rest © 2007-2017 by DWARF Standards Committee.