Acceptance of dwarf2/3 suggested form of DW_AT_comp_dir

Folks,

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.:

mg11-fc20.root.pri:/home/mg11/mydirectory/step.c

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.

thanks
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 www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

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 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 UNIX systems is
"hostname:pathname". If no hostname is available, the suggested form is ":pathname".

Apologies
Matt

Matthew Gardiner wrote:

Apologies for me getting noisy on this thread.

However, I don't think it's possible to work around toolchains that adopt the DWARF2/3 suggested form. The problem occurs if lldb wants to support debugging ELFs produced on different hosts - i.e. if the producer and consumers of the DWARF are either POSIX/Windows. We could then have a situation where a comp_dir string is something like:

c:/home/source

in this case, we cannot determine whether c is a drive-letter or a hostname.

(So, I think we'll be changing our toolchain accordingly :slight_smile:

However, if anyone has any opinions on this DWARF2/3 debate I'd be interested in hearing them.

Matt

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 www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

Apologies for me getting noisy on this thread.

However, I don't think it's possible to work around toolchains that adopt the DWARF2/3 suggested form. The problem occurs if lldb wants to support debugging ELFs produced on different hosts - i.e. if the producer and consumers of the DWARF are either POSIX/Windows. We could then have a situation where a comp_dir string is something like:

c:/home/source

Actually I think you will be ok because it will be:

c:\home\source for windows...

in this case, we cannot determine whether c is a drive-letter or a hostname.

(So, I think we'll be changing our toolchain accordingly :slight_smile:

However, if anyone has any opinions on this DWARF2/3 debate I'd be interested in hearing them.

Feel free to modify the DWARF parser to strip off the leading hostname to get things fixed and working. If it is part of the older _or_ current spec, we should support it in LLDB.

Greg

Greg Clayton wrote:

Apologies for me getting noisy on this thread.

However, I don't think it's possible to work around toolchains that adopt the DWARF2/3 suggested form. The problem occurs if lldb wants to support debugging ELFs produced on different hosts - i.e. if the producer and consumers of the DWARF are either POSIX/Windows. We could then have a situation where a comp_dir string is something like:

c:/home/source

Actually I think you will be ok because it will be:

c:\home\source for windows...

Ok, that's a pretty easy check to make first (i.e. single letter, :, then back-slash). Presumably if a windows toolchain uses / instead of \ then it's badly broken.

Adding zturner, if he should care to comment on the windows path.

in this case, we cannot determine whether c is a drive-letter or a hostname.

(So, I think we'll be changing our toolchain accordingly :slight_smile:

However, if anyone has any opinions on this DWARF2/3 debate I'd be interested in hearing them.

Feel free to modify the DWARF parser to strip off the leading hostname to get things fixed and working. If it is part of the older _or_ current spec, we should support it in LLDB.

No problem. I'll massage my current local change, to include the windows path check, then get it submitted.

thanks
Matt

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 www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

Hi Greg,

I've modified the DWARF parsing accordingly. See:

http://reviews.llvm.org/D5022

if you're happy with this, I'll submit on tuesday. It resulted in no regressions when I ran the python tests on linux.

Matt

Greg Clayton wrote:

Looks good. We can tweak it in the future if required if this ever fails.