[lldb-dev] Acceptance of dwarf2/3 suggested form of DW_AT_comp_dir
mg11 at csr.com
Thu Aug 21 02:45:42 PDT 2014
Sorry, my emailer messed up the extract from the DW_AT_comp_dir
definition. It should be:
A DW_AT_comp_dir attribute whose value is a null-terminated string
current working directory of the compilation command that produced this
in whatever form makes sense for the host system.
The suggested form for the value of the DW_AT_comp_dir attribute on UNIX
"hostname:pathname". If no hostname is available, the suggested form is
Matthew Gardiner wrote:
> The DWARF2/3 standard specifies DW_AT_comp_dir as follows:
> A DW_AT_comp_dir attribute whose value is a null-terminated string
> containing the
> current working directory of the compilation command that produced
> this compilation unit
> in whatever form makes sense for the host system.
> /The suggested form for the value of the DW_AT_comp_dir attribute on U
> NIX systems is//
> //‘‘hostname:pathname’’. If no hostname is available, the suggested
> form is ‘‘:pathname’’.//
> The section in italics (see the spec. for yourselves) is unfortunate,
> since in the Introduction we are told that italicised text are "not
> part of the format definition itself", but by using the word
> "suggested" in the definition the implies compliance with the definition.
> Consulting the DWARF4 standard's definition I see that the errant
> italicised text has been removed. (I say errant because in my opinion,
> the suggested form, contradicts the earlier requirement "makes sense
> for the host system", as the hostname:pathname or :pathname forms are
> not acceptable to the UNIXs stat or open functions).
> I note that the earlier versions of gcc ignored this "suggested form".
> Unfortunately the toolchain which I'm using follows the suggested form
> for UNIX systems, e.g.:
> This isn't currently acceptable to lldb, since when I am stepping an
> inferior, the DisplaySourceLinesXXX functions fail to perform, due to
> GetFileStats predictably failing when ::stat is passed a
> hostname:pathname style of string.
> Now I could get our toolchain fixed (so that it ignores DWARF2's
> suggestion, and encodes only the pathname), but I wondered whether it
> was worth seeing how the rest of the lldb community feels regarding
> supporting the suggested DWARF2/3 form.
> Matthew Gardiner
> Member of the CSR plc group of companies. CSR plc registered in
> England and Wales, registered number 4187346, registered office
> Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4
> 0WZ, United Kingdom
> More information can be found at www.csr.com. Keep up to date with CSR
> on our technical blog, www.csr.com/blog, CSR people blog,
> www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook,
> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> New for 2014, you can now access the wide range of products powered by
> aptX at www.aptx.com.
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> To report this email as spam click
More information about the lldb-dev