<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><div><span style="color:rgb(34,34,34)">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.</span><br></div></div></div></div></blockquote><div><br>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.<br><br>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.<br><br>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?<br><br>- David</div></div></div></div>