[Lldb-commits] [PATCH] D54670: 03/03: .debug_types: Update of D32167 (.debug_types) on top of D51578 (section concatenation)

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil added a comment.

In D54670#1403642 <https://reviews.llvm.org/D54670#1403642>, @labath wrote:

> I am still worried about the divergence from llvm's dwarf reader here.


I am still going to investigate your `DW_FORM_*` dispatching suggestion <https://reviews.llvm.org/D58330#1400847>.  It looks too simple to work, maybe it is the right way forward.

> the debug info can come from multiple sections? How come nobody else has this problem?

Because GDB does not need to return back to DWARF after it is parsed - but then for LLDB the multiple-sections dispatching could be done only for `user_id_t`

> Why not have `get_debug_types_data_extractor()` instead?

Because DataExtractor accesses always start at offset 0.

> BTW, I don't see a `get_debug_info_offset()`. AFAIK, there's no requirement that .debug_info has to come first in an object file. What would happen if the order of the sections in the object file is reversed?

It would fall back to the section-reading (instead of section-mmapping) less performing fallback in `get_debug_info_data()`.  If there are any such files out there sure the code could be extended to handle both orders of `.debug_info` and `.debug_types` but personally I do not think it is worth the code complication given there is the fallback anyway. I can put a warning there for such case so that it would be easily noticed in the future - but then maybe one could already rather extend the code, any suggestions what to choose?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54670/new/

https://reviews.llvm.org/D54670