[Dwarf-Discuss] implementing SFN, support for multiple views per PC
eager at eagercon.com
Thu Apr 27 18:33:26 PDT 2017
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
> In Section 6.2.5, page 160, add a Subsection "18.104.22.168 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
> * 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 22.214.171.124, 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 126.96.36.199, page 162, 1. DW_LNS_copy, line 10, add after
> "Then it": "increments the view register, ".
> In Section 188.8.131.52, 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 184.108.40.206, 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 220.127.116.11, 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 18.104.22.168, 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
> * 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 22.214.171.124]. 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
More information about the Dwarf-Discuss