[Dwarf-Discuss] implementing SFN, support for multiple views per PC

Michael Eager eager at eagercon.com
Thu Feb 23 12:44:10 PST 2017

Alexandre --

Please submit comments/proposals online at http://dwarfstd.org/Comment.php.

It greatly helps to specify the sections and pages that you propose
changing, as well as the text changed, added, or removed.

On 02/23/2017 12:00 PM, Alexandre Oliva wrote:
> On Sep  9, 2016, Alexandre Oliva <aoliva at redhat.com> wrote:
>> SFN stands for Statement Frontier Notes, a technique I specified several
>> years ago and presented at the GCC Summit to allow for finer-grained
>> location information, so as to enable debug information consumers to
>> compute/observe multiple views of an underlying program's state at the
>> same program counter.  More specifically, it would enable debuggers to
>> single-step over source code lines even though no actual instructions
>> were generated between the recommended breakpoints for those lines.
>> For some more details about the idea, please have a look at the paper
>> and the slides of the presentation at
>> http://people.redhat.com/aoliva/papers/sfn/
>> TL;DR: each state in the source program's execution in the target
>> language's virtual machine amounts to a view of the program state.  The
>> idea is to assign identifiers to (some) such views, and to add those
>> view identifiers to the line number table and to location lists.  This
>> message is about how to do accomplish that in a compact and
>> backward-compatible way.
> Here is a proposal of extension to support location views that I would
> like to submit for inclusion in DWARF 6.
> View numbers
> ------------
> A new column name "view" is added to the line number table.  It gets its
> own register, computed as follows.
> After appending a row to the line number matrix, the view register is
> incremented.
> Every opcode that changes the address register (but not the op_index),
> except for DW_LNS_fixed_advance_pc, resets the view register to zero at
> the time the address register is changed.
> Rationale: we just need view numbers to be unique within the same
> address, as a fractional part.  They might even be unique per op_index,
> but location lists represent addresses, so opcodes that advance only
> op_index will only reset the view when they advance the address, e.g. by
> exceeding maximum_operations_per_instruction in op_index.
> DW_LNS_fixed_advance_pc is available for compilers to use when an
> address changes is uncertain, e.g., when advancing past opcodes that may
> expand to an empty sequence, e.g. possibly-empty alignment sequences,
> optional no-operation opcodes or the like.
> View lists
> ----------
> A DIE with a DW_AT_location list may also have a DW_AT_locviews
> attribute referencing a viewlist table.
> For each range in the location list (not its terminator), the viewlist
> should contain a corresponding pair of entries, one corresponding to the
> views that start and end the range.  Each view is encoded as a separate
> uleb128 quantity.
> Each pair (address,view), formed by combining corresponding a beginning
> or end address from the location list with the corresponding view from
> the locviews view list, identifies the actual beginning or end of a
> view-augmented location list.
> Location lists that do not have a corresponding locviews list can be
> augmented by combining each one of its range addresses with a view
> number zero.  A locviews list whose entries are all zero is equivalent
> to an omitted locviews list.
> How's this to get the discussion on this extension started?
> This is implemented in GCC, GIT branch aoliva/SFN.  binutils+gdb branch
> users/aoliva/SFN has gas support for '.loc ... view' so as to generate
> more compact line number programs than GCC can on its own.

Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

More information about the Dwarf-Discuss mailing list