[Dwarf-Discuss] DWARF and source text embedding
scott at scottlinder.com
scott at scottlinder.com
Wed Jan 31 14:05:03 PST 2018
I am a compiler engineer at AMD, working on tools for debugging
programs. The problem I am attempting to solve was brought up previously
DWARF Standard issue 161018.1 titled "DWARF-embedded source for
programs", and is the result of runtimes like OpenCL doing online
in an environment where it is not desireable (or even feasible) to write
sources to disk. In these cases, it would be useful to support embedding
source directly in the resulting DWARF. I would like to propose a
solution to the one outlined in the above issue, but without structural
to the specification.
Add two new optional fields to the file_names prologue of the line
Add two bullets after "5. DW_LNCT_MD5"
DW_LNCT_has_source indicates that the value is a boolean which
interpretation of an accompanying DW_LNCT_source value. When present
must be an accompanying DW_LNCT_source value. When true, consumers
the embedded source instead of attempting to discover the source on
When false, consumers will ignore the DW_LNCT_source value. This
is always paired with a flag form (e.g. DW_FORM_flag or
DW_LNCT_source indicates that the value is a null-terminated string
is the original source text of the file. When present there must be
accompanying DW_LNCT_has_source value. The string will contain the
encoded source text with '\n' line endings. When the accompanying
DW_LNCT_has_source value is false, the value of DW_LNCT_source will
empty string. This code point is always paired with a string form
DW_FORM_string, DW_FORM_line_strp, DW_FORM_strp).
New type codes can be allocated for them in a backwards-compatible way,
codes for these new content types can be added in the range of
[DW_LNCT_lo_user, DW_LNCT_hi_user] to avoid changing the spec itself.
Add DW_LNCT_has_source 0x6
Add DW_LNCT_source 0x7
Any DWARFv5 consumer which is unaware of this extension would continue
operate as before, ignoring the new fields. Any consumer which is aware
extension would know to check DW_LNCT_has_source for each file_name
order to determine whether the embedded source field (DW_LNCT_source)
the source text of the corresponding file.
My team and I believe this simplifies the design by removing the need
changes to the compile unit sections, and by avoiding the addition of
file_name_entry_formats in a single program, all without sacrificing any
information. We have a preliminary implementation in LLVM/Clang, which
embedding source (clang -gdwarf-5 -gembed-source) and inspecting it via
llvm-dwarfdump and llvm-objdump (with the -source flag). The patches are
available at https://reviews.llvm.org/D42765 (LLVM) and
I would like any and all feedback on the design, and want to see about
possibility of adding the new content type codes outside of the "user"
(i.e. adding new entries for them in Table 7.27) in the next version of
More information about the Dwarf-Discuss