From davea42@linuxmail.org  Sun Apr  2 16:39:55 2017
From: davea42@linuxmail.org (David Anderson)
Date: Sun, 2 Apr 2017 09:39:55 -0700
Subject: [Dwarf-Discuss] split-dwarf, DWARF5 ELF object files requested
Message-ID: <4425adfe-c5ce-49f3-4a4c-ba9208b1fffb@linuxmail.org>

If you have DWARF5 ELF object files that you can provide to help
test libdwarf such object files would be much appreciated.
For example, you might be working on updating a compiler
to emit DWARF5 so you have such objects you generate
for testing.

I don't need or want the source code to the test objects.

Even if the ELF DWARF5 object files are somehow
imperfect they can still be helpful for my testing
of libdwarf.

The libdwarf/dwarfdump source on SourceForge.org now supports
DWARF5 split-dwarf.

If you want to contribute please email a note to libdwarf-list
at  linuxmail dot org.

Thanks in advance for any test objects.
David Anderson


From aoliva@redhat.com  Wed Apr 19 05:58:23 2017
From: aoliva@redhat.com (Alexandre Oliva)
Date: Wed, 19 Apr 2017 02:58:23 -0300
Subject: [Dwarf-Discuss] implementing SFN,
	support for multiple views per PC
In-Reply-To: <orwpbxzxhz.fsf@lxoliva.fsfla.org> (Alexandre Oliva's message of
	"Thu, 09 Mar 2017 23:17:12 -0300")
References: <orfup8zwow.fsf@livre.home> <orpoi865kg.fsf@lxoliva.fsfla.org>
	<58AF499A.3060405@eagercon.com> <orwpbxzxhz.fsf@lxoliva.fsfla.org>
Message-ID: <orwpah7xc0.fsf@lxoliva.fsfla.org>

On Mar  9, 2017, Alexandre Oliva <aoliva at redhat.com> wrote:

> a. a new kind of location list entry that specifies a pair of view
> numbers, that must be placed e.g. right before a bounded location
> description entry,

> b. several new kinds of location list entries, each corresponding to an
> existing bounded location description entry kind augmented with a pair
> of view numbers


> Now, my intent has been to make this extension backward-compatible, so
> that debug info consumers unaware of view numbers can still use the
> location lists.


> Is that so?  If loclists are really not supposed to be experimentally
> extensible, introducing a new experimental kind will be a bit of a
> challenge, even if it is proposed or even accepted for inclusion in
> future versions of the standard.


> So, before I elaborate either form, I'd appreciate feedback on which
> would be the preferred way to introduce this sort of extension:
> introduce new loclist kind or kinds, in spite of breaking backward
> compatibility of lists, or use a new attribute and list form to hold
> view numbers?


I got some private feedback suggesting I'd be better off proposing for
DWARF6 an extension to loclists, rather than a separate attribute, and
perhaps also some way to extend loclists in backward-compatible ways.

The latter is easy (as described in a. or b. above), but I'm having
trouble convincing myself that the latter can actually be done in a
sensible way.

We could have something in the CU that specified how to skip nonstandard
loclist entry kinds potentially used in the CU's loclists.  I envision a
few possibilities: specify the expected length of an entry kind in the
CU as a fixed quantity of bytes, or of leb128 values (interpretation of
uleb or sleb is up to the reader), or have each entry start with a
length.

Supporting all of these possibilities wouldn't be too hard, and I can
imagine uses for each of them, based on existing entry kinds and on the
view range extension I'm designing.

However, I can hardly imagine that a per-entry length would ever be
used: it wouldn't be very compact; such an entry kind would probably not
be standardized with an explicit length, so it would be forever a
nonstandard extension; and an indirection layer could make an explicit
length specification redundant (but then again it probably wouldn't end
up being standardized that way).

So, it would seem like we could make do with fixed-length extensions,
but even those could be introduced through additional attributes, rather
than as parts of loclists.

But then it hit me: the indirection layer mentioned above could help us
do away with even such fixed lengths: what if we had an entry kind that
added, to the present loclist, entries from another loclist, starting at
the entry whose address/offset is named, until its end-of-list entry (or
an unsupported entry kind) is reached?

We could then use this to factor out shared entries from loclists, and
also for nonstandard extensions (a reader not acquainted with them would
just take the unknown entry type as the end of the (sub?)list.

So now this renders the notion of CU-specified fixed-length extensions
redundant, and extensions can become standardized without encoding
changes, they just cease to be potential loclist-terminating entries
once they become part of the standard.

Given this, does anyone see any reason to still propose fixed-length
extensions "reserved" in the CU, as I described before?

Conversely, does anyone think we'd better not support extensions to
loclists whatsoever, not even through the "factoring" mechanism I
described above, and resort to additional attributes to experiment with
loclist extensions instead?


Thanks in advance for any feedback on these matters,

-- 
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


From aoliva@redhat.com  Fri Apr 28 00:43:49 2017
From: aoliva@redhat.com (Alexandre Oliva)
Date: Thu, 27 Apr 2017 21:43:49 -0300
Subject: [Dwarf-Discuss] implementing SFN,
	support for multiple views per PC
In-Reply-To: <58AF499A.3060405@eagercon.com> (Michael Eager's message of "Thu, 
	23 Feb 2017 12:44:10 -0800")
References: <orfup8zwow.fsf@livre.home> <orpoi865kg.fsf@lxoliva.fsfla.org>
	<58AF499A.3060405@eagercon.com>
Message-ID: <or1ssd1hve.fsf@lxoliva.fsfla.org>

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


From eager@eagercon.com  Fri Apr 28 01:33:26 2017
From: eager@eagercon.com (Michael Eager)
Date: Thu, 27 Apr 2017 18:33:26 -0700
Subject: [Dwarf-Discuss] implementing SFN,
 support for multiple views per PC
In-Reply-To: <or1ssd1hve.fsf@lxoliva.fsfla.org>
References: <orfup8zwow.fsf@livre.home> <orpoi865kg.fsf@lxoliva.fsfla.org>
	<58AF499A.3060405@eagercon.com> <or1ssd1hve.fsf@lxoliva.fsfla.org>
Message-ID: <59029BE6.8080207@eagercon.com>

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


