<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hello everyone<div class=""><br class=""></div><div class="">I am investigating a bug that prevents correct breakpoint resolution in LTO objects with embedded DWARF (no separate dSYM file) and tracked it down to the initialization of SymbolFileDWARFDebugMap. This code seems to assume there is only one compile unit per object file, but LTO objects have more than that:</div><div class=""><div class=""><br class=""></div><div class=""><font face="Menlo" style="font-size: 11px;" class="">void SymbolFileDWARFDebugMap::InitOSO() {</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class="">...</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> const uint32_t oso_index_count =</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> symtab->AppendSymbolIndexesWithTypeAndFlagsValue(</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> eSymbolTypeObjectFile, k_oso_symbol_flags_value, oso_indexes);</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class="">...</font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class=""> m_compile_unit_infos.resize(oso_index_count); // <—— one CU per OSO entry in the Symtab</span></font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""><br class=""></font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> for (uint32_t i = 0; i < oso_index_count; ++i) {</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> const uint32_t so_idx = oso_indexes[i] - 1;</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> const uint32_t oso_idx = oso_indexes[i];</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> const Symbol *so_symbol = symtab->SymbolAtIndex(so_idx);</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> const Symbol *oso_symbol = symtab->SymbolAtIndex(oso_idx);</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class="">...</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> const Symbol *last_symbol = symtab->SymbolAtIndex(sibling_idx - 1);</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> m_compile_unit_infos[i].first_symbol_index = so_idx;</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> m_compile_unit_infos[i].last_symbol_index = sibling_idx - 1;</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> m_compile_unit_infos[i].first_symbol_id = so_symbol->GetID();</font></div><div class=""><font face="Menlo" style="font-size: 11px;" class=""> m_compile_unit_infos[i].last_symbol_id = last_symbol->GetID();</font></div><div class=""><br class=""></div></div><div class="">The symptom is that LLDB will only read debug_line for one CU and miss all the rest. Thus, breakpoints in other CUs can’t be associated with line information.</div><div class=""><br class=""></div><div class="">I wonder if there is a good way to populate the correct number of compile units from the OSO entry at this point?</div><div class=""><br class=""></div><div class="">The situation may appear similar to an archive file with a number of objects, but then we have separate OSO entries like “path/to/lib/libLLVMMCParser.a(AsmLexer.cpp.o)”. Furthermore LTO objects have one common symtab for all compile units and it was probably mixed up by optimization, so we cannot simply say that CUs start/end at certain symbol indexes as in the above code. The latter is used rarely and only in SymbolFileDWARFDebugMap, so there may be a workaround, but first I have to figure out the initial question:</div><div class=""><br class=""></div><div class="">How to get more information about compile units in an LTO object? Any ideas welcome!</div><div class=""><br class=""></div><div class="">If that’s not possible, I may find another way to fix it further down the road, but then the name m_compile_unit_infos seems not exactly correct here. It’s rather something like m_referenced_object_infos, right?</div><div class="">Btw.: My first attempt was a workaround for the symptom (see <a href="https://reviews.llvm.org/D51546" class="">https://reviews.llvm.org/D51546</a>). It simply reads all debug_lines for a single CU, but I’d really appreciate a better solution.</div><div class=""><br class=""></div><div class="">Thanks</div><div class="">Stefan</div></body></html>