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

[Michael Eager]

Alexandre --

I don't know in what way the CAPTCHA "takes control of your computer",
but I'll add your proposals manually.


On 04/27/2017 05:43 PM, Alexandre Oliva wrote:
> 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
>
>


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