From nickc@redhat.com  Wed Jun  1 16:39:02 2016
From: nickc@redhat.com (Nick Clifton)
Date: Wed, 1 Jun 2016 17:39:02 +0100
Subject: [Dwarf-Discuss] doubt parsing CIE in eh_frame
In-Reply-To: <5744789E.4050900@linuxmail.org>
References: <CALCBA_HPzpDraJj7QAT7tRrOohY7Jj5qRwri4t32otkLNUX7qw@mail.gmail.com>
	<57439369.3090200@linuxmail.org>
	<CALCBA_Go7AdHg=urPocHuhCo9xinCK6dBUjfHVXaPxhGqoR0jg@mail.gmail.com>
	<20160524080747.GC28550@tucnak.redhat.com>
	<5744789E.4050900@linuxmail.org>
Message-ID: <bc7ece95-0bfc-2d78-91cd-6929773ea53a@redhat.com>

Hi David,

> The bug in readelf (I think) is at the end of display_debug_frames() in
> dwarf.c (binutils directory).
> 
> The frame_display_row call is a bit odd if all that exist are nops and
> results in the rax output

I am currently testing out the attached patch.  I am not sure however if
it is doing the right thing by just silently ignoring DW_CFA_NOPs.  Maybe
it should issue an interpretation along the lines of:

     LOC           CFA      ra      
  0000000000020480 nop      -

What do you think ?

Cheers
  Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dwarf.c.patch
Type: text/x-patch
Size: 1362 bytes
Desc: not available
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160601/c3d63485/attachment.bin>


From simon@codeplay.com  Thu Jun  9 14:12:01 2016
From: simon@codeplay.com (Simon Brand)
Date: Thu, 9 Jun 2016 15:12:01 +0100
Subject: [Dwarf-Discuss] DWARF and online-compiled programs
Message-ID: <3cbb6fdb-7a09-70ba-8834-0737b4f558af@codeplay.com>

Hi everyone,


I'm a member of the HSA Foundation (http://www.hsafoundation.com/) tools 
working group. We're currently working on tools and standards for 
debugging heterogeneous systems. There are many new problems which we 
are coming across in designing these solutions and we are hoping to 
involve other standards bodies in our efforts.


I'm writing this email in particular to address the problem of 
referencing source files in DWARF for online-compiled programs. The 
issue is that programming models such as OpenCL can often have source 
generated at runtime,which is compiled online, with its output not 
written to file. This raises an issue for the compiler: in the generated 
DWARF, what should it put as the file name of the compile unit and 
associated line table information?

Common solutions to this problem include generating some temporary 
source file name and having a contract with the debugger to get the 
source somehow and write it out to that file. Since OpenCL and friends 
generally have quite small source files, it's actually quite reasonable 
to embed the entire source in the binary, then have the debugger look in 
a known section or address to extract the source. If there was a way to 
express this in DWARF, then runtime-generated source files could work 
without an additional contract between the compiler and debugger.

I have written up a possible way in which this could be specified in the 
standard and am hoping for some advice on how we can develop this idea 
to solve our problem in a standard, uniform manner. I'm completely open 
to other solutions which fulfil our aims, so please feel free to suggest 
alternatives or major changes to this approach.

=========================================================================
Changes to compile unit sections:
These changes are pretty simple - I just add the possibility for the 
source to be identified by a DW_AT_location attribute instead of a 
DW_AT_name attribute.

Section 3.1.1:
Replace bullet 2 with this:
A DW_AT_name or DW_AT_location attribute identifying the primary source 
from which the compilation unit was derived. If a DW_AT_name attribute 
is used, its value is a nul-terminated string containing the full or 
relative path name of the source file. If a DW_AT_location attribute is 
used, its value is the virtual address of a null-terminated string 
containing the UTF-8 encoded source code.

Figure 42:
Add DW_AT_location to DW_TAG_compile_unit and DW_TAG_partial_unit entries.
=========================================================================


=========================================================================
Changes to line table sections:
I have based my modifications off of issue 140724.1. I don't know if 
this has since been modified, so there may be some inconsistencies.

These changes are a bit more complex, as there is currently the 
assumption that a given .debug_line section will only have a single 
file_name_entry_format. This would not support having a mix of usual 
source files and embedded source in the same program.

One solution would be to add the concept of a 'file name entry set', of 
which there can be more than one in a given header, and each can have 
its own file_name_entry_format. The header would contain a field 
specifying the number of file_name_entry_sets, then fields 17-21 would 
be repeated for each set. Another possibility would be to encode the 
sets in the same file_name_entry_format and file_names fields, but 
specify the sizes of each set. This is not quite as clear, but it seems 
desirable to avoid repeating the fields. I've sketched out the second 
option below.

------------------------------------------------------------------------
Field Field Name Value(s)
Number
1 Same as in Version 4 ...
2 version 5
3 Not present in Version 4 -
4 Not present in Version 4 -
5-12 Same as in Version 4 ...
13 directory_entry_format_count 1
14 directory_entry_format DW_LNCT_path, DW_FORM_string
15 directories_count <n+1>
16 directories <n+1>*<null terminated string>
17 file_name_entry_set_count 2
18 file_name_entry_format_set_counts 4,2
19 file_name_entry_format DW_LNCT_path, DW_FORM_string,
DW_LNCT_directory_index, DW_FORM_udata,
DW_LNCT_timestamp, DW_FORM_udata,
DW_LNCT_size, DW_FORM_udata,
DW_LNCT_location, DW_FORM_exprloc,
DW_LNCT_size, DW_FORM_udata

20 file_name_set_count <m>, <n>
21 file_names <m>*{<null terminated string>,
<index>, <timestamp>, <size>},
<n>*{<source location>, <size>}
------------------------------------------------------------------------

Section 6.2.4:
Add bullets after "16. directories"
17. file_name_entry_set_count (ubyte)
A count of the number of file name entry sets that occur in the 
following fields. If this field is zero, then the 
file_name_entry_format_set_sizes field (see below) must also be zero.

18. file_name_entry_format_set_counts (sequence of ubytes)
A sequence of counts of the number of entry formats for each file name 
entry set.

Section 6.2.4.1:
Add bullet after DW_LNCT_MD5
6. DW_LNCT_location
The component is the virtual address of a null-terminated string in 
memory containing the UTF-8 encoded source code. It is paired with the 
form DW_FORM_exprloc. Only one of DW_LNCT_path and DW_LNCT_location will 
be specified for a given file_name_entry_format.

Append paragraph to bullet 1:
Only one of DW_LNCT_path and DW_LNCT_location will be specified for a 
given file_name_entry_format.

Add paragraph after the first paragraph of bullet 2:
The index is 0 if the source is identified by a virtual address.

Table 7.25:
Add DW_LNCT_location 0x6 to the table

The description for DW_LNE_define_file may also need updating, although 
I don't know where to find the current version of this.

=========================================================================

Is this something which the committee would consider adopting? I'm happy 
to discuss any feedback you all have on this.

Regards,

Simon Brand

-- 
Simon Brand
Staff Software Engineer
Codeplay Software Ltd
Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it, or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY

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


From john.e.bishop@intel.com  Thu Jun  9 17:09:35 2016
From: john.e.bishop@intel.com (Bishop, John E)
Date: Thu, 9 Jun 2016 17:09:35 +0000
Subject: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)
Message-ID: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CBBBC@ORSMSX114.amr.corp.intel.com>

--[ quote ]--

I'm writing this email in particular to address the problem of referencing source files in DWARF for online-compiled programs. The issue is that programming models such as OpenCL can often have source generated at runtime,which is compiled online, with its output not written to file. This raises an issue for the compiler: in the generated DWARF, what should it put as the file name of the compile unit and associated line table information?

--[ end quote ]-



I'm inclined to say that in the general case the compiler should create an actual file and use it, but I like the in-the-binary solution for short pseudo-sources.



This would go into V6, right?




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


From paul.robinson@sony.com  Thu Jun  9 18:02:44 2016
From: paul.robinson@sony.com (Robinson, Paul)
Date: Thu, 9 Jun 2016 18:02:44 +0000
Subject: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)
In-Reply-To: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CBBBC@ORSMSX114.amr.corp.intel.com>
References: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CBBBC@ORSMSX114.amr.corp.intel.com>
Message-ID: <E3B07FDB86BFF041819DC057DEED8FEAD2D52A3C@USCULXMSG08.am.sony.com>

In principle you could have generated source JIT-compiled on a device that has no filesystem in the usual sense, or maybe has one but it isn't writable.
Seems like a reasonable approach.
--paulr

From: Dwarf-Discuss [mailto:dwarf-discuss-bounces@lists.dwarfstd.org] On Behalf Of Bishop, John E
Sent: Thursday, June 09, 2016 10:10 AM
To: dwarf-discuss at lists.dwarfstd.org
Subject: Re: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)


--[ quote ]--

I'm writing this email in particular to address the problem of referencing source files in DWARF for online-compiled programs. The issue is that programming models such as OpenCL can often have source generated at runtime,which is compiled online, with its output not written to file. This raises an issue for the compiler: in the generated DWARF, what should it put as the file name of the compile unit and associated line table information?

--[ end quote ]-



I'm inclined to say that in the general case the compiler should create an actual file and use it, but I like the in-the-binary solution for short pseudo-sources.



This would go into V6, right?




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


From simon@codeplay.com  Fri Jun 10 07:48:53 2016
From: simon@codeplay.com (Simon Brand)
Date: Fri, 10 Jun 2016 08:48:53 +0100
Subject: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEAD2D52A3C@USCULXMSG08.am.sony.com>
References: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CBBBC@ORSMSX114.amr.corp.intel.com>
	<E3B07FDB86BFF041819DC057DEED8FEAD2D52A3C@USCULXMSG08.am.sony.com>
Message-ID: <95abe7cb-b3fb-43fe-b823-3101e03967ae@codeplay.com>

Yes, although having the compiler create the file is reasonable in many 
cases, remote debugging of programs compiled on a device (which is a 
strong use-case for us) is more problematic, as the debugger would then 
need to download the generated source from the device and place it in 
the specified location in the DWARF, fix up the DWARF itself, or some 
other non-standard magic. HSA also doesn't mandate a filesystem and 
might be used on systems with read-only filesystems, so the scenario 
which Paul outlines is a real possibility.

I'm not familiar with the release schedule of the DWARF standard, so you 
all would be best to make that call. I read in the mailing list archives 
that the v5 deadline is long gone, so I guess v6 would be the target.

On 09/06/16 19:02, Robinson, Paul wrote:
>
> In principle you could have generated source JIT-compiled on a device 
> that has no filesystem in the usual sense, or maybe has one but it 
> isn't writable.
>
> Seems like a reasonable approach.
>
> --paulr
>
> *From:*Dwarf-Discuss [mailto:dwarf-discuss-bounces at lists.dwarfstd.org] 
> *On Behalf Of *Bishop, John E
> *Sent:* Thursday, June 09, 2016 10:10 AM
> *To:* dwarf-discuss at lists.dwarfstd.org
> *Subject:* Re: [Dwarf-Discuss] DWARF and online-compiled programs 
> (Simon Brand)
>
> --[ quote ]--
>
> I'm writing this email in particular to address the problem of 
> referencing source files in DWARF for online-compiled programs. The 
> issue is that programming models such as OpenCL can often have source 
> generated at runtime,which is compiled online, with its output not 
> written to file. This raises an issue for the compiler: in the 
> generated DWARF, what should it put as the file name of the compile 
> unit and associated line table information?
>
> --[ end quote ]?
>
> I?m inclined to say that in the general case the compiler should 
> create an actual file and use it, but I like the in-the-binary 
> solution for short pseudo-sources.
>
> This would go into V6, right?
>
>
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

-- 
Simon Brand
Staff Software Engineer
Codeplay Software Ltd
Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it, or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY

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


From ron.brender@gmail.com  Fri Jun 10 15:13:22 2016
From: ron.brender@gmail.com (Ron Brender)
Date: Fri, 10 Jun 2016 11:13:22 -0400
Subject: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEAD2D52A3C@USCULXMSG08.am.sony.com>
References: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CBBBC@ORSMSX114.amr.corp.intel.com>
	<E3B07FDB86BFF041819DC057DEED8FEAD2D52A3C@USCULXMSG08.am.sony.com>
Message-ID: <CANSbVThr4BFasKvCnbejVZR8fHgR3W-nGrmHFSToJZMdNehb+w@mail.gmail.com>

The original proposal extends DW_AT_location in a way that seems not really
in the spirit and intent of that attribute.

Two alternatives come to mind:

1) Invent a new pseudo-device to use in the name string of a standard
DW_AT_name attribute. For the name "inmemory:\\0x55555555", the debugger
would recognize the prefix and decode it's follow-on directly (sort of like
the "file:\\..." URL syntax supported in some browsers). This puts the
burden of agreement on the JIT and its debugger and requires nothing new of
DWARF as such.

2) Add a new implementation-defined attribute DW_AT_in_memory_source whose
class address value is the address in memory of the source string. Use this
attribute as an alternative to DW_AT_name. Since there is no named file
that contains the source, an omitted DW_AT_name (or one with a null string)
is sensible, This also requires nothing new of DWARF.

Something to consider...

Ron

On Thu, Jun 9, 2016 at 2:02 PM, Robinson, Paul <paul.robinson at sony.com>
wrote:

> In principle you could have generated source JIT-compiled on a device that
> has no filesystem in the usual sense, or maybe has one but it isn't
> writable.
>
> Seems like a reasonable approach.
>
> --paulr
>
>
>
> *From:* Dwarf-Discuss [mailto:dwarf-discuss-bounces at lists.dwarfstd.org] *On
> Behalf Of *Bishop, John E
> *Sent:* Thursday, June 09, 2016 10:10 AM
> *To:* dwarf-discuss at lists.dwarfstd.org
> *Subject:* Re: [Dwarf-Discuss] DWARF and online-compiled programs (Simon
> Brand)
>
>
>
> --[ quote ]--
>
> I'm writing this email in particular to address the problem of referencing
> source files in DWARF for online-compiled programs. The issue is that
> programming models such as OpenCL can often have source generated at
> runtime,which is compiled online, with its output not written to file. This
> raises an issue for the compiler: in the generated DWARF, what should it
> put as the file name of the compile unit and associated line table
> information?
>
> --[ end quote ]?
>
>
>
> I?m inclined to say that in the general case the compiler should create an
> actual file and use it, but I like the in-the-binary solution for short
> pseudo-sources.
>
>
>
> This would go into V6, right?
>
>
>
>
>
> _______________________________________________
> 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/20160610/9fef8884/attachment.htm>


From simon@codeplay.com  Mon Jun 13 08:07:33 2016
From: simon@codeplay.com (Simon Brand)
Date: Mon, 13 Jun 2016 09:07:33 +0100
Subject: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)
In-Reply-To: <CANSbVThr4BFasKvCnbejVZR8fHgR3W-nGrmHFSToJZMdNehb+w@mail.gmail.com>
References: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CBBBC@ORSMSX114.amr.corp.intel.com>
	<E3B07FDB86BFF041819DC057DEED8FEAD2D52A3C@USCULXMSG08.am.sony.com>
	<CANSbVThr4BFasKvCnbejVZR8fHgR3W-nGrmHFSToJZMdNehb+w@mail.gmail.com>
Message-ID: <cedf009d-93c6-956e-0822-cd51ebf15213@codeplay.com>

Thanks for your thoughts.

Could you expand on why this is not in the spirit of DW_AT_location?

Those two alternatives seem reasonable, but we'd really like to have a 
method standardised in DWARF for this so that the compiler and debugger 
don't need an additional contract between them.

Also, the source might not be "in memory", as it might be placed in a 
binary segment which is not loaded. The debugger should be interpreting 
the location as something like the ELF virtual address to locate the 
source in the object file.


On 10/06/16 16:13, Ron Brender wrote:
> The original proposal extends DW_AT_location in a way that seems not 
> really in the spirit and intent of that attribute.
>
> Two alternatives come to mind:
>
> 1) Invent a new pseudo-device to use in the name string of a standard 
> DW_AT_name attribute. For the name "inmemory:\\0x55555555", the 
> debugger would recognize the prefix and decode it's follow-on directly 
> (sort of like the "file:\\..." URL syntax supported in some browsers). 
> This puts the burden of agreement on the JIT and its debugger and 
> requires nothing new of DWARF as such.
>
> 2) Add a new implementation-defined attribute DW_AT_in_memory_source 
> whose class address value is the address in memory of the source 
> string. Use this attribute as an alternative to DW_AT_name. Since 
> there is no named file that contains the source, an omitted DW_AT_name 
> (or one with a null string) is sensible, This also requires nothing 
> new of DWARF.
>
> Something to consider...
>
> Ron
>
> On Thu, Jun 9, 2016 at 2:02 PM, Robinson, Paul <paul.robinson at sony.com 
> <mailto:paul.robinson at sony.com>> wrote:
>
>     In principle you could have generated source JIT-compiled on a
>     device that has no filesystem in the usual sense, or maybe has one
>     but it isn't writable.
>
>     Seems like a reasonable approach.
>
>     --paulr
>
>     *From:*Dwarf-Discuss
>     [mailto:dwarf-discuss-bounces at lists.dwarfstd.org
>     <mailto:dwarf-discuss-bounces at lists.dwarfstd.org>] *On Behalf Of
>     *Bishop, John E
>     *Sent:* Thursday, June 09, 2016 10:10 AM
>     *To:* dwarf-discuss at lists.dwarfstd.org
>     <mailto:dwarf-discuss at lists.dwarfstd.org>
>     *Subject:* Re: [Dwarf-Discuss] DWARF and online-compiled programs
>     (Simon Brand)
>
>     --[ quote ]--
>
>     I'm writing this email in particular to address the problem of
>     referencing source files in DWARF for online-compiled programs.
>     The issue is that programming models such as OpenCL can often have
>     source generated at runtime,which is compiled online, with its
>     output not written to file. This raises an issue for the compiler:
>     in the generated DWARF, what should it put as the file name of the
>     compile unit and associated line table information?
>
>     --[ end quote ]?
>
>     I?m inclined to say that in the general case the compiler should
>     create an actual file and use it, but I like the in-the-binary
>     solution for short pseudo-sources.
>
>     This would go into V6, right?
>
>
>     _______________________________________________
>     Dwarf-Discuss mailing list
>     Dwarf-Discuss at lists.dwarfstd.org
>     <mailto: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

-- 
Simon Brand
Staff Software Engineer
Codeplay Software Ltd
Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it, or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY

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


From palves@redhat.com  Mon Jun 13 10:28:37 2016
From: palves@redhat.com (Pedro Alves)
Date: Mon, 13 Jun 2016 11:28:37 +0100
Subject: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)
In-Reply-To: <cedf009d-93c6-956e-0822-cd51ebf15213@codeplay.com>
References: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CBBBC@ORSMSX114.amr.corp.intel.com>
	<E3B07FDB86BFF041819DC057DEED8FEAD2D52A3C@USCULXMSG08.am.sony.com>
	<CANSbVThr4BFasKvCnbejVZR8fHgR3W-nGrmHFSToJZMdNehb+w@mail.gmail.com>
	<cedf009d-93c6-956e-0822-cd51ebf15213@codeplay.com>
Message-ID: <7f03895d-bad3-3b3b-f754-41cd102d6df5@redhat.com>

(sorry for the double-post for those to got it, hadn't realized
this address wasn't subscribed to the list, and thus got rejected.)

On 06/13/2016 09:07 AM, Simon Brand wrote:

> Also, the source might not be "in memory", as it might be placed in a
> binary segment which is not loaded. The debugger should be interpreting
> the location as something like the ELF virtual address to locate the
> source in the object file.

In that case, wouldn't it be better to instead represent the source
as another debug string, with DW_FORM_string, or
.debug_str/DW_FORM_strp, or .debug_str_offsets/DW_FORM_strx, etc. ?

For example, add a new attribute, e.g., DW_AT_source, and in 3.1.1
where DW_AT_name is described:

 Compilation unit entries may have the following attributes:
 ...
 2. A DW_AT_name attribute whose value is a null-terminated string containing
 the full or relative path name of the primary source file from which the
 compilation unit was derived.

Change it to say either DW_AT_name or DW_AT_source.  Something like:

 2. Either a DW_AT_name attribute whose value is a null-terminated string
 containing the full or relative path name of the primary source file from
 which the compilation unit was derived, or a DW_AT_source attribute whose
 value is a null-terminated string containing the full contents of the source
 code from which the compilation unit was derived.

Thanks,
Pedro Alves



From john.e.bishop@intel.com  Mon Jun 13 12:54:17 2016
From: john.e.bishop@intel.com (Bishop, John E)
Date: Mon, 13 Jun 2016 12:54:17 +0000
Subject: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)
In-Reply-To: <7f03895d-bad3-3b3b-f754-41cd102d6df5@redhat.com>
References: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CBBBC@ORSMSX114.amr.corp.intel.com>
	<E3B07FDB86BFF041819DC057DEED8FEAD2D52A3C@USCULXMSG08.am.sony.com>
	<CANSbVThr4BFasKvCnbejVZR8fHgR3W-nGrmHFSToJZMdNehb+w@mail.gmail.com>
	<cedf009d-93c6-956e-0822-cd51ebf15213@codeplay.com>
	<7f03895d-bad3-3b3b-f754-41cd102d6df5@redhat.com>
Message-ID: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CD38D@ORSMSX114.amr.corp.intel.com>

> For example, add a new attribute, e.g., DW_AT_source, and in 3.1.1 where DW_AT_name is described:

However we point to the source code, we'd want to be able to do PC/line correlation; the line number table currently uses the source file name and the line (and column) numbers; the proposal should therefore explain how to reference the in-binary source in the line-number table create and how lines and columns are to be found in the in-binary source string.

	-John


From dearlam@qti.qualcomm.com  Wed Jun 15 13:31:53 2016
From: dearlam@qti.qualcomm.com (Earlam, David)
Date: Wed, 15 Jun 2016 13:31:53 +0000
Subject: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)
In-Reply-To: <cedf009d-93c6-956e-0822-cd51ebf15213@codeplay.com>
References: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CBBBC@ORSMSX114.amr.corp.intel.com>
	<E3B07FDB86BFF041819DC057DEED8FEAD2D52A3C@USCULXMSG08.am.sony.com>
	<CANSbVThr4BFasKvCnbejVZR8fHgR3W-nGrmHFSToJZMdNehb+w@mail.gmail.com>
	<cedf009d-93c6-956e-0822-cd51ebf15213@codeplay.com>
Message-ID: <3997e8173ce1430395c4bb9c2dfa5d6f@euamsexm01e.eu.qualcomm.com>

>From: Dwarf-Discuss [mailto:dwarf-discuss-bounces at lists.dwarfstd.org] On Behalf Of Simon Brand
>Sent: 13 June 2016 09:08
>Could you expand on why this is not in the spirit of DW_AT_location?

I'll try to answer this point.

I think re-using DW_AT_location for source code text lookup is "not in the spirit of DW_AT_location" because that attribute describes the place(s) in memory, register or stack frame - or combination of these - that the value of a _data object_ can be read (or written) by a DWARF consumer. Places plural, because the current live place holding a value can vary during a subprogram, influenced by register allocation optimisation decisions, for example.

The phrase 'location description' has had a meaning in the standard since DWARF1 was superseded by DWARF2 and is used to describe how data objects can be found (exact place in all the program's addressable memories including registers). In DWARF2 onwards, the  description of a data object's location can be present either inline in .debug_info  or as reference to a 'location list' in .debug_loc, or - since DWARF4 - be referenced from a DW_TAG_dwarf_procedure. See DWARF2 section 2.4, DWARF3 section 2.6 and DWARF4 section 2.6  and section 2.16.

All DW_AT_location in those specifications describe data objects and how to find them, not source code input texts.


David Earlam
Staff-Senior[Engineer]/Manager ? Software : Development Tools() {
Qualcomm Technologies International, Ltd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20160615/30d7c217/attachment.htm>


From simon@codeplay.com  Wed Jun 15 14:01:52 2016
From: simon@codeplay.com (Simon Brand)
Date: Wed, 15 Jun 2016 15:01:52 +0100
Subject: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)
In-Reply-To: <9294d7f9-2251-80ec-e6a9-35ef27d27cb1@redhat.com>
References: <8AA83D0D74B8AF4EB4D90F34FA7563D3586CBBBC@ORSMSX114.amr.corp.intel.com>
	<E3B07FDB86BFF041819DC057DEED8FEAD2D52A3C@USCULXMSG08.am.sony.com>
	<CANSbVThr4BFasKvCnbejVZR8fHgR3W-nGrmHFSToJZMdNehb+w@mail.gmail.com>
	<cedf009d-93c6-956e-0822-cd51ebf15213@codeplay.com>
	<9294d7f9-2251-80ec-e6a9-35ef27d27cb1@redhat.com>
Message-ID: <14d26d48-30c2-9d08-9813-16454e294347@codeplay.com>

This approach seems promising; it's probably easier to specify and keeps 
all the necessary information within DWARF. We'd definitely need to 
allow the line table and compile unit information to reference the same 
string so that there's no duplication.

Thanks,

Simon


On 13/06/16 11:22, Pedro Alves wrote:
> On 06/13/2016 09:07 AM, Simon Brand wrote:
>
>> Also, the source might not be "in memory", as it might be placed in a
>> binary segment which is not loaded. The debugger should be interpreting
>> the location as something like the ELF virtual address to locate the
>> source in the object file.
> In that case, wouldn't it be better to instead represent the source
> as another debug string, with DW_FORM_string, or
> .debug_str/DW_FORM_strp, or .debug_str_offsets/DW_FORM_strx, etc. ?
>
> For example, add a new attribute, e.g., DW_AT_source, and in 3.1.1
> where DW_AT_name is described:
>
>   Compilation unit entries may have the following attributes:
>   ...
>   2. A DW_AT_name attribute whose value is a null-terminated string containing
>   the full or relative path name of the primary source file from which the
>   compilation unit was derived.
>
> Change it to say either DW_AT_name or DW_AT_source.  Something like:
>
>   2. Either a DW_AT_name attribute whose value is a null-terminated string
>   containing the full or relative path name of the primary source file from
>   which the compilation unit was derived, or a DW_AT_source attribute whose
>   value is a null-terminated string containing the full contents of the source
>   code from which the compilation unit was derived.
>
> Thanks,
> Pedro Alves
>

-- 
Simon Brand
Staff Software Engineer
Codeplay Software Ltd
Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it, or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY

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


From Vineet.Gupta1@synopsys.com  Mon Jun 27 13:40:48 2016
From: Vineet.Gupta1@synopsys.com (Vineet Gupta)
Date: Mon, 27 Jun 2016 13:40:48 +0000
Subject: [Dwarf-Discuss] [PATCH] ARC: gas: Generate offset with Default
	CFA
References: <1467032706-7684-1-git-send-email-vgupta@synopsys.com>
Message-ID: <C2D7FE5348E1B147BCA15975FBA23075010694604B@us01wembx1.internal.synopsys.com>

On Monday 27 June 2016 06:35 PM, Vineet Gupta wrote:
> This makes the kernel dwarf stack unwinder work again which expects an
> offset with default CFA in the initial instructions.
>
> gas	* config//tc-arc.c (tc_arc_frame_initial_instructions): Use
> 	cfi_add_CFA_def_cfa to generate default CFA with offset
>
> Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
> ---
>  gas/ChangeLog | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/gas/ChangeLog b/gas/ChangeLog
> index 2a28352f77a6..0033f91865e1 100644
> --- a/gas/ChangeLog
> +++ b/gas/ChangeLog
> @@ -1,3 +1,8 @@
> +2016-06-27  Vineet Gupta <vgupta at synopsys.com>
> +
> +	* config//tc-arc.c (tc_arc_frame_initial_instructions): Use
> +	cfi_add_CFA_def_cfa to generate default CFA with offset
> +
>  2016-06-27  Trevor Saunders  <tbsaunde+binutils at tbsaunde.org>
>  
>  	* config/tc-dlx.c: Include bfd/elf32-dlx.h.

Oops - this was clearly vaporware with only changelog - no real code !


From Vineet.Gupta1@synopsys.com  Mon Jun 27 13:41:07 2016
From: Vineet.Gupta1@synopsys.com (Vineet Gupta)
Date: Mon, 27 Jun 2016 19:11:07 +0530
Subject: [Dwarf-Discuss] [PATCH v2] ARC: gas: Generate offset with Default
	CFA
In-Reply-To: <1467032706-7684-1-git-send-email-vgupta@synopsys.com>
References: <1467032706-7684-1-git-send-email-vgupta@synopsys.com>
Message-ID: <1467034867-8288-1-git-send-email-vgupta@synopsys.com>

This makes the kernel dwarf stack unwinder work again which expects an
offset with default CFA in the initial instructions.

gas	* config//tc-arc.c (tc_arc_frame_initial_instructions): Use
	cfi_add_CFA_def_cfa to generate default CFA with offset

Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
---
 gas/ChangeLog       | 5 +++++
 gas/config/tc-arc.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gas/ChangeLog b/gas/ChangeLog
index 2a28352f77a6..0033f91865e1 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,8 @@
+2016-06-27  Vineet Gupta <vgupta at synopsys.com>
+
+	* config//tc-arc.c (tc_arc_frame_initial_instructions): Use
+	cfi_add_CFA_def_cfa to generate default CFA with offset
+
 2016-06-27  Trevor Saunders  <tbsaunde+binutils at tbsaunde.org>
 
 	* config/tc-dlx.c: Include bfd/elf32-dlx.h.
diff --git a/gas/config/tc-arc.c b/gas/config/tc-arc.c
index 575582178209..f651600746de 100644
--- a/gas/config/tc-arc.c
+++ b/gas/config/tc-arc.c
@@ -4160,7 +4160,7 @@ void
 tc_arc_frame_initial_instructions (void)
 {
   /* Stack pointer is register 28.  */
-  cfi_add_CFA_def_cfa_register (28);
+  cfi_add_CFA_def_cfa(28, 0);
 }
 
 int
-- 
2.5.0



From eager@eagercon.com  Mon Jun 27 15:05:54 2016
From: eager@eagercon.com (Michael Eager)
Date: Mon, 27 Jun 2016 08:05:54 -0700
Subject: [Dwarf-Discuss] [PATCH v2] ARC: gas: Generate offset with
 Default CFA
In-Reply-To: <1467034867-8288-1-git-send-email-vgupta@synopsys.com>
References: <1467032706-7684-1-git-send-email-vgupta@synopsys.com>
	<1467034867-8288-1-git-send-email-vgupta@synopsys.com>
Message-ID: <577140D2.70604@eagercon.com>

The DWARF-Discuss mailing list is for questions and discussion about
DWARF.  It is not for patches to programs which produce, consume, or
otherwise use DWARF.

On 06/27/2016 06:41 AM, Vineet Gupta wrote:
> This makes the kernel dwarf stack unwinder work again which expects an
> offset with default CFA in the initial instructions.
>
> gas	* config//tc-arc.c (tc_arc_frame_initial_instructions): Use
> 	cfi_add_CFA_def_cfa to generate default CFA with offset
>
> Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
> ---
>   gas/ChangeLog       | 5 +++++
>   gas/config/tc-arc.c | 2 +-
>   2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/gas/ChangeLog b/gas/ChangeLog
> index 2a28352f77a6..0033f91865e1 100644
> --- a/gas/ChangeLog
> +++ b/gas/ChangeLog
> @@ -1,3 +1,8 @@
> +2016-06-27  Vineet Gupta <vgupta at synopsys.com>
> +
> +	* config//tc-arc.c (tc_arc_frame_initial_instructions): Use
> +	cfi_add_CFA_def_cfa to generate default CFA with offset
> +
>   2016-06-27  Trevor Saunders  <tbsaunde+binutils at tbsaunde.org>
>
>   	* config/tc-dlx.c: Include bfd/elf32-dlx.h.
> diff --git a/gas/config/tc-arc.c b/gas/config/tc-arc.c
> index 575582178209..f651600746de 100644
> --- a/gas/config/tc-arc.c
> +++ b/gas/config/tc-arc.c
> @@ -4160,7 +4160,7 @@ void
>   tc_arc_frame_initial_instructions (void)
>   {
>     /* Stack pointer is register 28.  */
> -  cfi_add_CFA_def_cfa_register (28);
> +  cfi_add_CFA_def_cfa(28, 0);
>   }
>
>   int
>


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


