"Entries in this sequence describe each path that was searched for included source files in this compilation. (The paths include those directories specified explicitly by the user for the compiler to search and those the compiler searches without explicit direction.) Each path entry is either a full path name or is relative to the current directory of the compilation."

                                                                          
I think that at the time I had interpreted that has “if the user passes -I../include to the compiler, le line table should list ../include as a directory in the line table”. I think my interpretation was too strict though and that we could canonicalize the file/dir names as we’d like.
The compilation dir will always be there as a special entry. It’s the implicit entry 0 in the directory list, but it’s value is not stored in the line table, it is a normal string that is referenced by the TAG_compile_unit DIE. If it is extracted from an MDFile, we need to make sure this one doesn’t get mangled, but I think this is the only one we really need to preserve.
It's not clear to me *which* references need that, but I guesswe need to sort out exactly what the requirements are so we knowwhich way to canonicalize things.  I wonder if this only mattersfor DW_TAG_compile_unit?  If so, we could canonicalize freelyeverywhere else.  (For example, we could store a `path:` nodeeverywhere (dropping the filename/directory distinction, orcanonicalizing it to basename/dirname, etc.), and add a `cwd:`to the compile unit.)
As stated above, I think we are free to canonicalize as we wish.
David also pointed out (in a previous thread about this) thatthe frontend (or `DIBuilder`) might be the right location forcanonicalization.  Certainly, we couldn't canonicalize `..`references without access to the filesystem (at least not onPOSIX platforms), but maybe we don't care about that anyway?
What I attempted to do in the past was exactly that, canonicalize ‘..’ in the paths (The lldb folks would have loved to be able to consider file identifiers as unique in the line table). 
Fred
">

(original) (raw)


On Feb 20, 2015, at 11:14 AM, Duncan P. N. Exon Smith <dexonsmith@apple.com> wrote:


On 2015-Feb-20, at 09:44, Frédéric Riss <friss@apple.com> wrote:

Speaking of deduplication of filenames. I think we discussed that in the early stages of your work, but I just wanted to make sure I remember correctly: the new debug hierarchy will allow to implement specific uniquing behavior, right? So we will be able to tweak MDFile to unique:

!MDFile(filename: "path/to/file", directory: "/path/to/dir")
!MDFile(filename: "to/file", directory: "/path/to/dir/path")

into the same object? I did some work in this area and in the current form it’s not really possible to do cleanly (don’t remember the details here, but I know punted it till we get smart uniquing capability).

IIRC, there was some talk about how the DWARF spec requires that
references to a \`directory\` need to be the CWD of the compiler.

If you refer to a conversation we had, I’m pretty sure I was referring to this text in the standard about the directories listed in the line table:

"Entries in this sequence describe each path that was searched for included source files in this compilation. (The paths include those directories specified explicitly by the user for the compiler to search and those the compiler searches without explicit direction.) Each path entry is either a full path name or is relative to the current directory of the compilation."

I think that at the time I had interpreted that has “if the user passes -I../include to the compiler, le line table should list ../include as a directory in the line table”. I think my interpretation was too strict though and that we could canonicalize the file/dir names as we’d like.

The compilation dir will always be there as a special entry. It’s the implicit entry 0 in the directory list, but it’s value is not stored in the line table, it is a normal string that is referenced by the TAG\_compile\_unit DIE. If it is extracted from an MDFile, we need to make sure this one doesn’t get mangled, but I think this is the only one we really need to preserve.

It's not clear to me \*which\* references need that, but I guess
we need to sort out exactly what the requirements are so we know
which way to canonicalize things. I wonder if this only matters
for DW\_TAG\_compile\_unit? If so, we could canonicalize freely
everywhere else. (For example, we could store a \`path:\` node
everywhere (dropping the filename/directory distinction, or
canonicalizing it to basename/dirname, etc.), and add a \`cwd:\`
to the compile unit.)

As stated above, I think we are free to canonicalize as we wish.

David also pointed out (in a previous thread about this) that
the frontend (or \`DIBuilder\`) might be the right location for
canonicalization. Certainly, we couldn't canonicalize \`..\`
references without access to the filesystem (at least not on
POSIX platforms), but maybe we don't care about that anyway?

What I attempted to do in the past was exactly that, canonicalize ‘..’ in the paths (The lldb folks would have loved to be able to consider file identifiers as unique in the line table).

Fred