[Dwarf-Discuss] .debug_line include_directories semantic worth

[Roland McGrath]

The specification (in v4, 6.2.5, item 11) describes an inherent
semantic meaning for the set of directory names in a .debug_line
table (and implies a semantic meaning to their order).  

Does anyone consider those semantics actually worthwhile?

The specification says that the sequence of directory names
indicates the include search path used at compile time (i.e. in
C-like languages, the list used for #include).  That is some
semantically meaningful information about the compilation, though
it's not very clear what a consumer would do with that knowledge in
practice.

To my knowledge, GCC has never followed this part of the specification.
It chooses the directory table entries arbitrarily, considering solely
their value in abbreviating the complete source file names used in that
table, so that the file name entries can be shorter.

Do other compilers actually emit the ordered sequence of directory
names that made up the search path applied to #include directives at
compile time?

Do any DWARF consumers use the directory table for its own semantic
value, i.e., anything other than composing the full file names for
the source files named in the file table?

If nobody is actually either emitting or using this data as it's
specified, then IMHO it makes sense for a future revision of the
standard to relax the specification so that there is no purpose for
the directory names other than as an encoding device to shorten the
file table.

I can imagine only one or two ways a consumer might actually ever
provide anything to a user based on this information, and those only
by stretching to come up with one.  For example, a display of source
code corresponding to a particular compilation described by DWARF
could associate #include lines in the source with particular source
files.  But for displaying the verbatim source code that was
compiled, that is more easily done by looking at the .debug_macinfo
records to see what effect this source line's #include actually had.
So really it's only for an IDE to answer the question, "Which file
would I get if I had written '#include <foo>' or '#include "bar"'
somewhere in this compilation?"

Is that the only thing it's good for?  Can people cite other uses,
actual or potential?  If not, then I can't really justify fixing GCC
to follow the letter of the specification here.


Thanks,
Roland