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

[Alexandre Oliva]

On Feb 23, 2017, Michael Eager <eager at eagercon.com> wrote:

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

I can't.  It says "robot verification failed" :-(

I guess that's because my web condom (GNU LibreJS) keeps Google's
non-Free CAPTCHA Software from taking control of my computer.

Is there any way to bypass the proprietary third-party code, or any
other way to submit the following two enhancement proposals?

(both proposals, Location View Numbering and Extending Loclists,
separated by ^----$ below, were authored by myself, in case anyone else
can get them into the proposal database somehow)

Thanks in advance,


=======================
Location View Numbering
=======================

This proposal introduces a new implicit column to the line number
table, namely "view numbers", so that multiple program states can be
identified at the same program counter, and extends loclists with
means to add view numbers to address ranges, enabling locations to
start or end at specific views.

This may improve debug information, enabling generators to indicate
inlined entry points and preferred breakpoints for statements even if
instructions associated with the corresponding source locations were
not emitted at the given PC, and to emit variable locations that
indicate the initial values of inlined arguments, and side effects of
operations as they would be expected to take effect from the source
code, even when multiple statements have their side effects all
encoded at the same PC: with view numbers, debug information consumers
may be able to logically advance the perceived program state, so as to
reflect user-expected changes specified in the source code, even if
the operations were reordered or optimized out in the executable code.



View numbers
------------

In Section 6.2, page 149, line 4: change "with one row" to "with at
least one row".  Before line 11, add a bullet "a view number,
identifying a logical program state".

In Section 6.2.2, page 150, add to Table 6.3, between 'address' and
'op_index', a new register named "view", defined as "An unsigned
integer that identifies each distinct entry associated with the same
'address' in the line number matrix."

In Section 6.2.2, page 152, add before line 1 the following sentence:
"The address and view registers, taken together, identify a logical
state within the source program."

In Section 6.3, page 153, add to Table 6.4 a line "view | 0" after
address.

In Section 6.2.5, page 160, add a Subsection "6.2.5.0  View Numbers":

  View numbers identify multiple logical states of the source program
  that are all associated with the same address in the program.

  View numbers are computed as a side effect of line number opcodes,
  observing the following rules:

  * opcodes that modify the address register (with the exception of
    DW_LNS_fixed_advance_pc) simultaneously reset the view register to
    zero

  * opcodes that append a row to the matrix subsequently increment the
    view register

  Rationale: location lists can refer to address and view, not
  op_index, so views are reset at address changes, not at op_index
  changes.  Opcodes that advance op_index only will only reset the
  view when they happen to advance the address, e.g. by exceeding
  maximum_operations_per_instruction in op_index.

  DW_LNS_fixed_advance_pc is the only opcode that may change the
  address without resetting the view.  It is available for compilers
  to use when an address change 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.

In Section 6.2.5.1, page 160, insert before item 3: "Reset the view
register if the value of the address register changed in 2.", and
after item 3: "Increment the view register"

In Section 6.2.5.2, page 162, 1. DW_LNS_copy, line 10, add after
"Then it": "increments the view register, ".

In Section 6.2.5.2, page 162, append to the description of
2. DW_LNS_advance_pc: "Then, if the value of the address register
changed, it resets the view register to zero."

In Section 6.2.5.2, page 163, append to the first paragraph of
8. DW_LNS_const_add_pc: ", and it resets the view register to zero if
the value of the address register changed."

In Section 6.2.5.2, page 163, add a third paragraph to
9. DW_LNS_fixed_advance_pc: "This is the only address-changing opcode
that does NOT reset the view register.  It helps compilers that emit
line number programs to determine view numbers even when advancing
past opcodes that might expand to nothing."

In Section 6.2.5.3, page 164, in 2. DW_LNE_set_address, change
"op_index register" to "view and op_index registers".



Views in loclists
-----------------

In Section 2.6.2, page 43, add a bullet before "Default location
description":

  * View description.  This kind of entry must precede a Bounded
  location description, and it augments the starting and ending
  address of the Bounded location description with [view numbers|link
  to 6.2.5.0].  The addresses of a bounded location description that
  is not preceded by a view description are argumented with view
  number zero.

In Section 2.6.2, page 45, add before 6++. DW_LLE_default_location:

  6. DW_LLE_view_pair

  This is the only form of view description, and it has two unsigned
  LEB128 operands.  The first and second values specify respectively
  the view numbers that augment the starting and ending addresses of
  the bounded location description the view description precedes.

In Section 7.7.3, add to Table 7.10 the following entry:

  DW_LLE_view_pair | 0x09

----

==================
Extending loclists
==================

This proposal introduces an extension mechanism to loclists, that can
be used to share location list fragments among multiple location
lists, and to experiment with extensions to location list standards in
a way that does not break backward compatibility and that enables the
experimental extensions to be welcomed into the standard without
encoding changes.


In Section 2.6.2:

  * List extension.  This kind of entry extends a location list with
    entries from another loclist.  It can be used to share list
    entries among multiple lists, and also to extend location lists
    with nonstandard entry kinds, in a way that will be disregarded by
    debug information consumers that do not support the extensions.

In Section 2.6.2, page 44, add to 1. DW_LLE_end_of_list:

  Any non-standard entry kind may be interpreted as a
  DW_LLE_end_of_list entry.

  2. DW_LLE_extend_loclistx

  This is a form of list extension, that has one unsigned LEB128
  operand.  The value is an index into the .debug_loclists section,
  like the operand of a DW_FORM_loclistx loclist.  The contents of the
  location identified by the index are added to the base to determine
  the address of the first entry of a loclist whose entries are to be
  regarded as part of the loclist containing the list extension entry.

In Section 2.6.2, page 45, add after 9. DW_LLE_start_length:

  10. DW_LLE_extend_loclist

  This is a form of list extension, that has one offset operand.  The
  value is an offset into the .debug_loclists section, like the
  operand of a DW_FORM_sec_offset loclist.  The offset identifies the
  first entry of a loclist whose entries are to be regarded as part of
  the loclist containing the list extension entry.

In Section 7.7.3, add to Table 7.10:

  DW_LLE_extend_loclist  | 0x0A
  DW_LLE_extend_loclistx | 0x0B


-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer