Hi all,
I was the author of the original proposal for DWARF source text
embedding, and my use case was OpenCL kernel code, which is often
generated at runtime. For debugging, this generated source needs to be
embedded in the binary in many cases since you may not have a writeable
file system,
Hi,
On 2018-02-13 16:45:23 -0800, Michael Eager wrote:
> I can imagine situations where embedding ephemeral generated source in a
> DWARF debug entry can make sense. But I have the feeling that there is
> more to this in your environment than what I imagine. Can you give a
> description of the u
On 02/13/18 09:37, sc...@scottlinder.com wrote:
Michael, Paul,
In the current proposal, it is not an error to have any value (including an
empty string) in the _source attribute when the _has_source flag is
true, which
allows for embedding an empty source string.
After seeing more feedback on
Michael,
In the case of this proposal, then, I suggest the CU fields
(AT_{name,comp_dir}) retain their exact current definitions. Language
implementations, regardless of whether they might want to support
embedding
source, currently use the filesystem. This extension is essentially just
cachein
Michael, Paul,
In the current proposal, it is not an error to have any value (including
an
empty string) in the _source attribute when the _has_source flag is
true, which
allows for embedding an empty source string.
After seeing more feedback on this point, I think you are right that the
ext
On 02/01/2018 08:07 AM, sc...@scottlinder.com wrote:
Hi John,
In the case where the files are actually available on disk, and the
source is simply being "cached", the attributes are exactly the same. In
the case where sources are generated, and so have no true path on disk,
I would suggest we
On 02/01/2018 12:01 PM, sc...@scottlinder.com wrote:
Hi Paul,
My intention was to support an empty source string; I want to be
explicit about the presence of embedded source for each file.
I'm not fond of the belt and suspenders approach. If there is one
specifier for an attribute, there's n
> -Original Message-
> From: sc...@scottlinder.com [mailto:sc...@scottlinder.com]
> Sent: Thursday, February 01, 2018 12:02 PM
> To: Robinson, Paul; dwarf-discuss@lists.dwarfstd.org
> Subject: RE: [Dwarf-Discuss] DWARF and source text embedding
>
> Hi Paul,
>
Hi Paul,
My intention was to support an empty source string; I want to be
explicit about the presence of embedded source for each file.
When reading the spec I did notice places where an empty string can
indicate the absence of the attribute (e.g. DW_AT_name), but I would
prefer to be explic
> -Original Message-
> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On
> Behalf Of sc...@scottlinder.com
> Sent: Wednesday, January 31, 2018 2:05 PM
> To: dwarf-discuss@lists.dwarfstd.org
> Subject: [Dwarf-Discuss] DWARF and source text embedding
>
> Hello all,
>
Hi John,
In the case where the files are actually available on disk, and the
source is simply being "cached", the attributes are exactly the same. In
the case where sources are generated, and so have no true path on disk,
I would suggest we might just leave the exact meaning to be
implementat
Hi Scott,
Question: What does the DW_TAG_compile_unit look like for an embedded source
file? For example, what does the DW_AT_name and DW_AT_comp_dir look like?
Cheers, John D.
On 01/31/18 17:05, sc...@scottlinder.com wrote:
> Hello all,
>
> I am a compiler engineer at AMD, working on tools fo
Hi Scott --
Please submit your proposal at http://dwarfstd.org/Comment.php.
On 01/31/2018 02:05 PM, sc...@scottlinder.com wrote:
Hello all,
I am a compiler engineer at AMD, working on tools for debugging
online-compiled
programs. The problem I am attempting to solve was brought up previousl
13 matches
Mail list logo
