Hello everyone
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:
void SymbolFileDWARFDebugMap::InitOSO() {
...
const uint32_t oso_index_count =
symtab->AppendSymbolIndexesWithTypeAndFlagsValue(
eSymbolTypeObjectFile, k_oso_symbol_flags_value, oso_indexes);
...
m_compile_unit_infos.resize(oso_index_count); // <—— one CU per OSO entry in
the Symtab
for (uint32_t i = 0; i < oso_index_count; ++i) {
const uint32_t so_idx = oso_indexes[i] - 1;
const uint32_t oso_idx = oso_indexes[i];
const Symbol *so_symbol = symtab->SymbolAtIndex(so_idx);
const Symbol *oso_symbol = symtab->SymbolAtIndex(oso_idx);
...
const Symbol *last_symbol = symtab->SymbolAtIndex(sibling_idx - 1);
m_compile_unit_infos[i].first_symbol_index = so_idx;
m_compile_unit_infos[i].last_symbol_index = sibling_idx - 1;
m_compile_unit_infos[i].first_symbol_id = so_symbol->GetID();
m_compile_unit_infos[i].last_symbol_id = last_symbol->GetID();
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.
I wonder if there is a good way to populate the correct number of compile units
from the OSO entry at this point?
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:
How to get more information about compile units in an LTO object? Any ideas
welcome!
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?
Btw.: My first attempt was a workaround for the symptom (see
https://reviews.llvm.org/D51546). It simply reads all debug_lines for a single
CU, but I’d really appreciate a better solution.
Thanks
Stefan_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
