From John.DelSignore@roguewave.com  Fri Feb  3 20:21:28 2017
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Fri, 3 Feb 2017 15:21:28 -0500
Subject: [Dwarf-Discuss] Does any compiler implement Split DWARF as
 described in the current DWARF5 draft standard?
Message-ID: <662765da-2bb0-78b9-ec4c-0ef6697c43af@roguewave.com>

An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20170203/d48a0c74/attachment.htm>


From paul.robinson@sony.com  Fri Feb  3 20:31:37 2017
From: paul.robinson@sony.com (Robinson, Paul)
Date: Fri, 3 Feb 2017 20:31:37 +0000
Subject: [Dwarf-Discuss] Does any compiler implement Split DWARF as
 described in the current DWARF5 draft standard?
In-Reply-To: <662765da-2bb0-78b9-ec4c-0ef6697c43af@roguewave.com>
References: <662765da-2bb0-78b9-ec4c-0ef6697c43af@roguewave.com>
Message-ID: <E3B07FDB86BFF041819DC057DEED8FEA0109C87B68@USCULXMSG08.am.sony.com>

It's on my personal roadmap to do DWARF 5 split-DWARF for LLVM, but there's no timeframe.  I promise it won't be soon. ?
--paulr

From: Dwarf-Discuss [mailto:dwarf-discuss-bounces@lists.dwarfstd.org] On Behalf Of John DelSignore
Sent: Friday, February 03, 2017 12:21 PM
To: dwarf-discuss at lists.dwarfstd.org
Subject: [Dwarf-Discuss] Does any compiler implement Split DWARF as described in the current DWARF5 draft standard?


Hi,

I've been poking around looking for Split DWARF producers. As far as I can tell, no compiler or tool chain currently implements Split DWARF as described in the current DWARF5 draft standard. Is that correct?

The GNU, Intel, and LLVM compilers implement the GNU DebugFission flavor of Split DWARF, which is close to the DWARF5 draft standard but differs in some non-trivial ways.  The GNU DebugFission format has gone through several revisions, and depending on the version of the tool chain, will produce a .gdb_index section with a version ranging from 4 to 7, so even it is a moving target.

In any case, does anyone know...

  1.  Are there any compilers out there that currently produce Split DWARF as described in the current DWARF5 draft standard?
  2.  Are there compilers (including Intel, GNU, and LLVM) that plan to add DWARF5 Split DWARF support?
  3.  Are there other compilers (except for Intel, GNU, and LLVM) that produce DebugFission Split DWARF?

Thanks, John D.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20170203/cf46fe14/attachment-0001.htm>


From davea42@linuxmail.org  Fri Feb  3 22:29:49 2017
From: davea42@linuxmail.org (David Anderson)
Date: Fri, 3 Feb 2017 14:29:49 -0800
Subject: [Dwarf-Discuss] Does any compiler implement Split DWARF as
 described in the current DWARF5 draft standard?
In-Reply-To: <662765da-2bb0-78b9-ec4c-0ef6697c43af@roguewave.com>
References: <662765da-2bb0-78b9-ec4c-0ef6697c43af@roguewave.com>
Message-ID: <d9eb51da-51fa-7524-f22f-27e607adce22@linuxmail.org>

On 02/03/2017 12:21 PM, John DelSignore wrote:
> Hi,
> 
> I've been poking around looking for Split DWARF producers. As far as I
> can tell, no compiler or tool chain currently implements Split DWARF as
> described in the current DWARF5 draft standard. Is that correct?
> 
>

gcc did it for DWARF4.  I have a couple test objects
that were contributed for libdwarf testing.
It would be...impossible? to have done DWARF5
yet since we made major changes in the last few weeks (CU header
lengths and contents (contents a bit further in the past),
for example).


DavidA.


From jakub@redhat.com  Fri Feb  3 22:35:18 2017
From: jakub@redhat.com (Jakub Jelinek)
Date: Fri, 3 Feb 2017 23:35:18 +0100
Subject: [Dwarf-Discuss] Does any compiler implement Split DWARF as
 described in the current DWARF5 draft standard?
In-Reply-To: <d9eb51da-51fa-7524-f22f-27e607adce22@linuxmail.org>
References: <662765da-2bb0-78b9-ec4c-0ef6697c43af@roguewave.com>
	<d9eb51da-51fa-7524-f22f-27e607adce22@linuxmail.org>
Message-ID: <20170203223518.GS14051@tucnak>

On Fri, Feb 03, 2017 at 02:29:49PM -0800, David Anderson wrote:
> On 02/03/2017 12:21 PM, John DelSignore wrote:
> > Hi,
> > 
> > I've been poking around looking for Split DWARF producers. As far as I
> > can tell, no compiler or tool chain currently implements Split DWARF as
> > described in the current DWARF5 draft standard. Is that correct?
> > 
> >
> 
> gcc did it for DWARF4.  I have a couple test objects
> that were contributed for libdwarf testing.
> It would be...impossible? to have done DWARF5
> yet since we made major changes in the last few weeks (CU header
> lengths and contents (contents a bit further in the past),
> for example).

With -gdwarf-5 in GCC we've implemented most of the DWARF5 changes (ok,
still e.g. need to change DW_TAG_member to DW_TAG_variable for
static data members), but the major exception is the -gsplit-dwarf
stuff, only very small amount of changes have been done in that
direction.  I must say I'm not familiar enough even with what
tools have been used for -gsplit-dwarf, the compiler generates
both sets of sections but then something needs to split off the
*.dwo files, so the only changes that were done for -gsplit-dwarf
were just eyeballed by looking at the assembly.

	Jakub


From John.DelSignore@roguewave.com  Fri Feb  3 22:56:19 2017
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Fri, 3 Feb 2017 17:56:19 -0500
Subject: [Dwarf-Discuss] Does any compiler implement Split DWARF as
 described in the current DWARF5 draft standard?
In-Reply-To: <d9eb51da-51fa-7524-f22f-27e607adce22@linuxmail.org>
References: <662765da-2bb0-78b9-ec4c-0ef6697c43af@roguewave.com>
	<d9eb51da-51fa-7524-f22f-27e607adce22@linuxmail.org>
Message-ID: <e29710d2-0a99-04d5-5b05-1f3999428b3e@roguewave.com>

On 02/03/17 17:29, David Anderson wrote:
> On 02/03/2017 12:21 PM, John DelSignore wrote:
>> Hi,
>>
>> I've been poking around looking for Split DWARF producers. As far as I
>> can tell, no compiler or tool chain currently implements Split DWARF as
>> described in the current DWARF5 draft standard. Is that correct?
>>
>>
> gcc did it for DWARF4.  I have a couple test objects
> that were contributed for libdwarf testing.

Are you referring to the vendor extensions GNU added for the DebugFission flavor of Split DWARF described here <https://gcc.gnu.org/wiki/DebugFission>? AFAIK, the DWARF4 Standard had no support for Split DWARF at all.

> It would be...impossible? to have done DWARF5
> yet since we made major changes in the last few weeks (CU header
> lengths and contents (contents a bit further in the past),
> for example).

OK, fair enough. But I guess I'm trying to also figure out where Split DWARF is headed. Are all of the producer going to converge on DWARF5 eventually, and if so when? And in the meantime, is it worth supporting the DebugFission flavor of Split DWARF, and where is that headed?

Cheers, John D.

>
>
> DavidA.
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>



From John.DelSignore@roguewave.com  Fri Feb  3 23:01:57 2017
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Fri, 3 Feb 2017 18:01:57 -0500
Subject: [Dwarf-Discuss] Does any compiler implement Split DWARF as
 described in the current DWARF5 draft standard?
In-Reply-To: <20170203223518.GS14051@tucnak>
References: <662765da-2bb0-78b9-ec4c-0ef6697c43af@roguewave.com>
	<d9eb51da-51fa-7524-f22f-27e607adce22@linuxmail.org>
	<20170203223518.GS14051@tucnak>
Message-ID: <50c68fbc-1fe4-c5d5-31ef-d5872d9dab6a@roguewave.com>

On 02/03/17 17:35, Jakub Jelinek wrote:
> On Fri, Feb 03, 2017 at 02:29:49PM -0800, David Anderson wrote:
>> On 02/03/2017 12:21 PM, John DelSignore wrote:
>>> Hi,
>>>
>>> I've been poking around looking for Split DWARF producers. As far as I
>>> can tell, no compiler or tool chain currently implements Split DWARF as
>>> described in the current DWARF5 draft standard. Is that correct?
>>>
>>>
>> gcc did it for DWARF4.  I have a couple test objects
>> that were contributed for libdwarf testing.
>> It would be...impossible? to have done DWARF5
>> yet since we made major changes in the last few weeks (CU header
>> lengths and contents (contents a bit further in the past),
>> for example).
> With -gdwarf-5 in GCC we've implemented most of the DWARF5 changes (ok,
> still e.g. need to change DW_TAG_member to DW_TAG_variable for
> static data members), 

OK, thanks, that's good to hear. Any idea when -gdwarf-5 support in GCC will appear in the mainstream? If I wanted a copy of GCC that implements the latest DWARF5 Split DWARF support, where should I look?

Thanks, John D.

> but the major exception is the -gsplit-dwarf
> stuff, only very small amount of changes have been done in that
> direction.  I must say I'm not familiar enough even with what
> tools have been used for -gsplit-dwarf, the compiler generates
> both sets of sections but then something needs to split off the
> *.dwo files, so the only changes that were done for -gsplit-dwarf
> were just eyeballed by looking at the assembly.
>
> 	Jakub
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>



From echristo@gmail.com  Fri Feb  3 23:45:10 2017
From: echristo@gmail.com (Eric Christopher)
Date: Fri, 03 Feb 2017 23:45:10 +0000
Subject: [Dwarf-Discuss] Does any compiler implement Split DWARF as
 described in the current DWARF5 draft standard?
In-Reply-To: <e29710d2-0a99-04d5-5b05-1f3999428b3e@roguewave.com>
References: <662765da-2bb0-78b9-ec4c-0ef6697c43af@roguewave.com>
	<d9eb51da-51fa-7524-f22f-27e607adce22@linuxmail.org>
	<e29710d2-0a99-04d5-5b05-1f3999428b3e@roguewave.com>
Message-ID: <CALehDX4W0ag73pvn-j5z3GUgVgTeXYkLnB-CDaCFC9WQobkmMg@mail.gmail.com>

On Fri, Feb 3, 2017 at 2:56 PM John DelSignore <
John.DelSignore at roguewave.com> wrote:

> On 02/03/17 17:29, David Anderson wrote:
> > On 02/03/2017 12:21 PM, John DelSignore wrote:
> >> Hi,
> >>
> >> I've been poking around looking for Split DWARF producers. As far as I
> >> can tell, no compiler or tool chain currently implements Split DWARF as
> >> described in the current DWARF5 draft standard. Is that correct?
> >>
> >>
> > gcc did it for DWARF4.  I have a couple test objects
> > that were contributed for libdwarf testing.
>
> Are you referring to the vendor extensions GNU added for the DebugFission
> flavor of Split DWARF described here <
> https://gcc.gnu.org/wiki/DebugFission>? AFAIK, the DWARF4 Standard had no
> support for Split DWARF at all.
>
> > It would be...impossible? to have done DWARF5
> > yet since we made major changes in the last few weeks (CU header
> > lengths and contents (contents a bit further in the past),
> > for example).
>
> OK, fair enough. But I guess I'm trying to also figure out where Split
> DWARF is headed. Are all of the producer going to converge on DWARF5
> eventually, and if so when? And in the meantime, is it worth supporting the
> DebugFission flavor of Split DWARF, and where is that headed?
>
>
Probably on both. Lots of producers already emit the existing split dwarf
support and while the changes aren't major they're at least "something".

Basically I'd suggest supporting both just on the "there are released
compilers that emit something".

-eric


> >
> >
> > DavidA.
> > _______________________________________________
> > Dwarf-Discuss mailing list
> > Dwarf-Discuss at lists.dwarfstd.org
> > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> >
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20170203/33c3fa94/attachment.htm>


From eager@eagercon.com  Wed Feb 15 20:10:46 2017
From: eager@eagercon.com (Michael Eager)
Date: Wed, 15 Feb 2017 12:10:46 -0800
Subject: [Dwarf-Discuss] DWARF Version 5 Standard Released
Message-ID: <58A4B5C6.1000006@eagercon.com>

The DWARF Debugging Information Format Standards Committee is pleased to announce the availability 
of Version 5 of the DWARF Debugging Format Standard.   The DWARF Debugging Format is used to 
communicate debugging information between a compiler and debugger to make it easier for programmers 
to develop, test, and debug programs.

DWARF is used by a wide range of compilers and debuggers, both proprietary and open source, to 
support debugging of Ada, C, C++, Cobol, FORTRAN, Java, and other programming languages. DWARF V5 
adds support for new languages like Rust, Swift, Ocaml, Go, and Haskell, as well as support for new 
features in older languages. DWARF can be used with a wide range of processor architectures, such as 
x86, ARM, PowerPC, from 8-bit to 64-bit.

DWARF is the standard debugging format for Linux and several versions of Unix and is widely used 
with embedded processors. DWARF is designed to be extended easily to support new languages and new 
architectures.

The DWARF Version 5 Standard has been in development for six years. DWARF Committee members include 
representatives from over a dozen major companies with extensive experience in compiler and debugger 
development. Version 5 incorporates improvements in many areas: better data compression, separation 
of debugging data from executable files, improved description of macros and source files, faster 
searching for symbols, improved debugging of optimized code, as well as numerous improvements in 
functionality and performance.

The DWARF Version 5 Standard can be downloaded without charge from the DWARF website (dwarfstd.org). 
Additional information about DWARF, including how to subscribe to the DWARF mailing list, can also 
be found on the website. Questions about the DWARF Debugging Information Format or the DWARF 
Committee can be directed to the DWARF Committee Chair, Michael Eager at info at dwarfstd.org.

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


From aoliva@redhat.com  Thu Feb 23 20:00:15 2017
From: aoliva@redhat.com (Alexandre Oliva)
Date: Thu, 23 Feb 2017 17:00:15 -0300
Subject: [Dwarf-Discuss] implementing SFN,
	support for multiple views per PC
In-Reply-To: <orfup8zwow.fsf@livre.home> (Alexandre Oliva's message of "Fri,
	09 Sep 2016 16:42:55 -0300")
References: <orfup8zwow.fsf@livre.home>
Message-ID: <orpoi865kg.fsf@lxoliva.fsfla.org>

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.

-- 
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  Thu Feb 23 20:44:10 2017
From: eager@eagercon.com (Michael Eager)
Date: Thu, 23 Feb 2017 12:44:10 -0800
Subject: [Dwarf-Discuss] implementing SFN,
 support for multiple views per PC
In-Reply-To: <orpoi865kg.fsf@lxoliva.fsfla.org>
References: <orfup8zwow.fsf@livre.home> <orpoi865kg.fsf@lxoliva.fsfla.org>
Message-ID: <58AF499A.3060405@eagercon.com>

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


