<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 16, 2023 at 9:12 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 16, 2023 at 8:57 AM Alexander Yermolovich <<a href="mailto:ayermolo@meta.com" target="_blank">ayermolo@meta.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>




<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
For background llvm discussion on how to implement it: <br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<a href="https://discourse.llvm.org/t/debuginfo-dwarfv5-lld-debug-names-with-fdebug-type-sections/73445" id="m_-7544006485526254189m_9129383029566457905LPlnk198509" target="_blank">https://discourse.llvm.org/t/debuginfo-dwarfv5-lld-debug-names-with-fdebug-type-sections/73445</a><br>
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Thanks for explaining the issue, and proposing spec change. <span id="m_-7544006485526254189m_9129383029566457905🙂">🙂<br>
</span></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span id="m_-7544006485526254189m_9129383029566457905😄">The question I have. Is non-bit identical TUs with the same hash a fundamental issue that needs to be addressed somehow in the next version of the spec? If we could have such guarantee that should simplify things quite a bit. The linker can just
 follow the same path as for functions. Compiler can generate symbol name unique for the type unit hash. So, when linker comdats TU sections entries in TU list will point to correct address and no special logic is needed for tombstone. I guess there is a hashing
 mechanism in DWARF spec, but LLVM is not using it. Should we go back to it, is it enough?<br></span></div></div></div></blockquote><div><br></div><div>The hashing mechanism in the spec doesn't guarantee bit-identicality, I believe. It's structural equivalence (eg: if you produce the main type DIE followed by an int DIE that the main type needs, or you emit the int DIE first, followed by the main type DIE - these hash to the same value (because you start from the type DIE and hash outwards/to what it can reach, and has structural equivalence - int is int, no matter what offset it's at)) not bit identical. For a bunch of reasons this is preferable.<br><br>(yes, clang takes this further and hashes based on the C++ ODR - which is off-spec, but workable in our experience)<br><br>I was thinking another direction we could go is that, I think, the only things in a type unit that can be referenced is the type (I think?) then perhaps we could modify how types defined in type units are referenced.<br><br>If only the type can be referenced in a type unit, we could emit a .debug_names entry without a DW_IDX_die_offset - just the DW_IDX_type_unit - and the consumer can use the header of the type unit to find the exact type unit DIE.<br><br>Are there any other things that could be referenced within a type unit?</div></div></div></blockquote><div><br>Hmm - this doesn't really relate to the local TU tombstoning issue (since that's tombstoning the reference to the unit) but would help address the foreign TU situation - in the DWP case, a consumer could ignore the DW_IDX_compile_unit alongside the DW_IDx_type_unit and look up that type in the DWP - then use the type unit's header to find the type DIE. </div></div></div>