[PATCH] Add a DWOId field to DICompileUnit (so DWARF skeleton CUs can be expression in IR).

[David Blaikie]

>
> I’ve been thinking some more about this and I’m no longer opposed to just
> straight using the clang module id as the dwo_id. It has the big advantage
> of being very cheap to extract from the module, plus we don’t need to
> compute DWARF hash then. Realizing that it is quite improbable that the
> clang module cache is purged while building a project, we might as well go
> ahead and use the existing random module hash and then fix clang’s module
> hash to become deterministic if that should turn out to be problem in
> practice.
>

I believe this random number is already broken by design (well, certainly
breaks Google's lovely caching build system which is why I believe it's
disabled in explicit modules builds). Now that the (currently observed)
indeterminacy in output has been fixed by Chandler, there's probably no
reason to have the ID in the modules at all.

But, yes, a prescriptive hash to use for the dwo_id from the frontend would
be nice, I think. I assume that would also provide the necessary
verification for AST-loading debuggers like LLDB will be.

Richard: We talked about this ages ago with you, in the sense that we
tapped you on the shoulde,r asked if there was an identifier/number/hash
for the module and you said "yes". I guess that was probably this (now
understood to be problematic) random number? Or is there already a
good/better/useful hash of a module as well taht we could use instead? If
not, do you have a rough idea about whether one could be reasonably created?

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150518/43f354f9/attachment.html>