[LLVMdev] Questions before moving the new debug info hierarchy into place

Duncan P. N. Exon Smith dexonsmith at apple.com
Fri Feb 20 11:14:14 PST 2015


> On 2015-Feb-20, at 09:44, Frédéric Riss <friss at 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.

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

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?



More information about the llvm-dev mailing list