Re: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)

2016-06-13 Thread Simon Brand 

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:\\0x", 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 > 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-boun...@lists.dwarfstd.org
] *On Behalf Of
*Bishop, John E
*Sent:* Thursday, June 09, 2016 10:10 AM
*To:* dwarf-discuss@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@lists.dwarfstd.org

http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org




___
Dwarf-Discuss mailing list
Dwarf-Discuss@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

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)

2016-06-13 Thread Pedro Alves 
(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

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] DWARF and online-compiled programs (Simon Brand)

2016-06-13 Thread Bishop, John E 
> 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
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org