[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