<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/93886>93886</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
debug_names incorrect parent due to collision between CU and TU
</td>
</tr>
<tr>
<th>Labels</th>
<td>
debuginfo
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
dwblaikie
</td>
</tr>
</table>
<pre>
from https://github.com/llvm/llvm-project/pull/91808#issuecomment-2138480664
```
namespace A {
namespace B {
struct C { };
struct D { };
} // namespace B
} // namespace A
void f1(A::B::C, A::B::D) { }
```
```
$ clang++-tot names.cpp -g2 -O0 -gpubnames -c -fdebug-types-section && llvm-dwarfdump-tot -debug-names names.o | grep "Name \|Entry \|Tag: \|DW_IDX\|String: "
```
```
String: 0x000000a0 "_Z2f1N1A1B1CENS0_1DE"
Entry @ 0xe5 {
Tag: DW_TAG_subprogram
DW_IDX_die_offset: 0x00000023
DW_IDX_parent: <parent not indexed>
```
```
String: 0x000000b5 "A"
Entry @ 0xeb {
Tag: DW_TAG_namespace
DW_IDX_type_unit: 0x00
DW_IDX_die_offset: 0x00000023
DW_IDX_parent: <parent not indexed>
Entry @ 0xf1 {
Tag: DW_TAG_namespace
DW_IDX_type_unit: 0x01
DW_IDX_die_offset: 0x00000023
DW_IDX_parent: <parent not indexed>
Entry @ 0xf7 {
Tag: DW_TAG_namespace
DW_IDX_die_offset: 0x00000044
DW_IDX_parent: <parent not indexed>
```
```
String: 0x000000b7 "B"
Entry @ 0x103 {
Tag: DW_TAG_namespace
DW_IDX_type_unit: 0x00
DW_IDX_die_offset: 0x00000025
DW_IDX_parent: Entry @ 0xe5
Entry @ 0x10d {
Tag: DW_TAG_namespace
DW_IDX_type_unit: 0x01
DW_IDX_die_offset: 0x00000025
DW_IDX_parent: Entry @ 0xf1
Entry @ 0x117 {
Tag: DW_TAG_namespace
DW_IDX_die_offset: 0x00000046
DW_IDX_parent: Entry @ 0xf7
```
So the second and third "B" entries match up with the appropriate "A" entries, but the first jumps over to refer to a different DIE in the CU that has the same offset.
This is because the UniqueID on a unit is only unique within that type of unit (it's unique across CUs and, separately, unique across TUs) - so the "DieOffsetAndUnitID" is not a globally unique identifier for an entry - it'd need the type of unit in there too to completely uniquify it.
Adding this patch is enough to expose the issue more directly:
```
diff --git a/llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp b/llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp
index 5b679fd3b9f9..cc8b8d1881ed 100644
--- a/llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp
+++ b/llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp
@@ -615,8 +615,10 @@ Dwarf5AccelTableWriter::Dwarf5AccelTableWriter(
for (auto &Bucket : Contents.getBuckets())
for (auto *Hash : Bucket)
- for (auto *Value : Hash->getValues<DWARF5AccelTableData *>())
- IndexedOffsets.insert(Value->getDieOffsetAndUnitID());
+ for (auto *Value : Hash->getValues<DWARF5AccelTableData *>()) {
+ auto Inserted = IndexedOffsets.insert(Value->getDieOffsetAndUnitID()).second;
+ assert(Inserted);
+ }
populateAbbrevsMap();
}
```
The two different units (one CU, one TU) with the same unit ID end up colliding in the `IndexedOffsets` set - and only one ends up in there, and so then the loop here:
```
for (OffsetAndUnitID Offset : IndexedOffsets)
DIEOffsetToAccelEntryLabel.insert({Offset, Asm->createTempSymbol("")});
```
Only inserts the copy once, oh... and /this/ code:
```
if (EmittedAccelEntrySymbols.insert(EntrySymbol).second)
Asm->OutStreamer->emitLabel(EntrySymbol);
```
Silently skips emitting the label even though it matches more than one entry unintentionally, because it can match more than one entry /intentionally/ (if there's multiple entries for exactly the same entity, but known by different names (like the mangled name and unmangled name)).
So, yeah.
Hmm, I guess at least the type unit number probably isn't gapless - there are cases where we create a type unit and then potentially throw it away (see the TypeUnitsUnderConstruction stuff) - but we don't reuse the type unit number.
So, maybe it's possible to use a single numbering for CUs and TUs, gaps and all?
The only thing I was worried about was that some code might be using the numbering to index into an array of units at some point, but if that's not the case - great! Probably more intuitive that they be totally unique numbers.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJy8WNty4zjOfhrmBiWXRPl44QvbimdS9f_dU5tke2tvUpQEyZyWSA1Jxe233wIpn9JJnzK7LldiUgD4AQSBjxLWylohLtlkzSbZjejdTptluc8bIT9LvMl1eVhWRrewc66zLF0xvmV8W0u36_NRoVvGt03zfPwXdUb_iYVjfNv1TcP4dpHM4znjqbS2x0K3LSoX8SSdj-fxdDpmccbi1fB3Gg9fP1SiRduJAmEFbLZ-Obk-T1pn-sLBhmaAzTKWXj_IvnrAZhlAcAUuTH7r4QDyWcsSqoTx-Yqika7W4d-G8Q1cT2WML04rv-bhyyEfQ9EIVTO-ZnwdOe3C-qOi6yCqOUQfY4jqrs_9NEQFRFWJeV9H7tChjSwWTmoFjE8Zn4LfkXIvTFX2beftRUE86AfjGthsA7XBDhjnH0SLwCYbNtvcKmcOw-8HUbN0NQyyT0932b_C73tnpArPOP8RL8F_zmrxl9h_REwWnv7Nq-RDskrWyeb2w338lGS3J8NBdYA1jiH-gpNzFsDwGaBmn54eVr892T7vjK6NaK-lgg9PpcQnXVUW3SUWng7Cg1QnDCovwdJNGIDSDqQq8QuWLL19j-f5hDxffcvN_HtunvL0GjilxVOv5Mm7_0EQvoZfJT8L_xrfSy-Sa2DfgX9t6x1ezH5xE17HNx6_C98vptqMUm39jVRL4vTv3ayfSrnJd2Jyffbf9qH8m85L8ivgv4m6St5Enfx0gv0IrPH0h2DNXk8r__deg9shWCy0KkGoEtxOmvKYSoDKGYkWWuGKHfQd7KXbeRXRdUZ3RgqHxxp3lKZ-mffOi1XSWAd_9m1nQT-jAafBYBV-CChlVaE_CdndLUjldTaP4HbCwU7YgI4aV3B_dAn-YSctSAs5FqK36GUflfyrx7sMtAIBtN8koVVzoMFfPXoP_ELCASUF6CrIMT6XjvGZPUqKwmhrYfNoKTLklcVOGOGwOdDoWuzh0RIriMCGmDLOM4kfPeyVKh-VdHcZRUlaf-wF1I3ORXNGJktUTlYSDVTagFA-oAeIwOMqQSGW3vYV7hA1g-C0pqgWuu0aJJDBsKwOIK8jtypLqWraawud31ppAZXu6x1ZwC-dHuLpyR202iCU0mDhmgNRoNcyivYSoqiWDsQFd5Q549uNLvE3VIxvV7b9w0jl0NCgKLB5EHmDngjlv6QWVvdVFCb5dLaoyjRfVIvRqCjm-bxM5vMES0jieHqszFEU_SLGI59bh--7ILNxTEc0miYTxjdzYHwdfiYxDM8yoniTs_InI8leIKGvP-PzoSqcKgklE-Nz0TtN_HHdF5_RAdWJjVYOlbOjGl2YtqTPF_Q9F6JrA6vfhd159aByko3gNel_iqZHL056EUtva3R-0rJ0k31a_WN74UQmnCAt6obXSCK4C40yHCk7ksqicYzPvbHB8GtH7mjmdEXg6_8S0nOVP60B4M3febBYAkuz9zoyCuX6yh9hBxvHhV51-HRdOSdHp7u-EQ5XeW7w2f6_6IZ1jspv3nEeqBDt9UUNp3JkKaJaURWnGkm_Hh4pNKfO4cu5r1x3GaAqqa0Uummkr0lDD2DT-DpKbBqDRQeR71K-oJNtVKUlA8ciSGuSQCjCwVajdQf-4RuVa8iDF_GGMPYJ8QLL-XRkd7dh8kH71PCd9_9Ejs15W9lsHWT8RdK2tMOFQeHwAdvu_tDmuvFB5_67oIBf7t412I_kerAd2mOhO4pF4X3Xu9Fo5CPA-JbqO111C12-6busyPXbVjqH5dmFgOoiNy9mL1LwFIjBrY-9u3cGRYuGhthK54PxlYG3vLuXDSrXHMB-lp0FMuBCq0JoyBLgs99W36ukC8yEGAq1KLcTakgLapy9kr6-Sa2oz3peMnAF6aAQauA1r-kyvn2hvPUMoTrm2cxC2zdOdg2eaBIlEn4R1CXPqU423OFIij4rvVeQHy6OTbiyMz5v5OfQdVuh6gZL_8RvZq8up4YycE3kaIEDit3V9O9tS_N3UPdoLQgHDQrrziTCn0PVtzka6IzORU7ZZRXjMwe16BpSiwaCIQxCISxa2PvxHiHkMYgLa4FFooJO-_h5iuN2Ru8p6mIvKLhzi8HVh0OHdN7soyrRbLQKb3akVmBdX1WBU1Hk9gilDsAMHvneSydG8HVUWnHIEQZu12lrZd4QWwIyIsBKiuygT7lGuziQvsDqNhSJMBZNw9LtNQvFUI6IVtZwB3thYa-NkViCyDUh90RWOLC6RX8aoZX1zkGO0Ntjep8BOB0uhSAVsWQFwhhxOBI-v43eUqelcsfE8pkpgpPEL31pEBYhgpo2ifEE_jjusM94qVwvnXzGgQzv8ECInHaXrDTAskNa3ZTLtFykC3GDy2SWzJJ4HsfTm90yxwUvJ2kaY8lxGqdxxSfxYlzOyjROp2J8I5c85uN4ksac8-l4MlpMFwLLeDKeTaq8KBM2jrEVshkRnxppU9948rlcpPP59MYffutfZ3LuX3VJVWkqmJPsxiz9C7G8ry0bx420zp6tOOkaXHqVcM0CqQptiMzCcA0vewzMuWmkpdTL0e0RFV1FQhbc9KZZ_vSbUu8AleDgw_OS_ycAAP__8wKGkg">