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

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I am still worried about the divergence from llvm's dwarf reader here. We now have a relatively nice Object API, which presents a view of the object file that everybody is used to (i.e., as a bunch of sections). This includes the llvm object and dwarf readers, and the DWARF spec (!). But now we are drilling a hole in that API, which basically reverts the sections and gives us back the a view of the object file as a stream of bytes. And if the object file happens to be compressed, then we have to mock up a new uncompressed buffer with all of the data, even though the compression is supposed to be transparent and unobtrusive (and it mostly is, if you stick to viewing the object file as a collection of sections). All because our dwarf reader cannot handle the fact that the debug info can come from multiple sections? How come nobody else has this problem?

Treating dwarf data as a single buffer with various chunks starting at random offsets should essentially be isomorphous with treating it as a collection of independent buffers. We are here introducing a function called `get_debug_types_offset`. Why not have `get_debug_types_data_extractor()` instead? That may mean some functions need to be changed so that they take an additional buffer argument, instead of just assuming everything refers to the single grand buffer, but I think that's a good thing, because it brings us closer to reality instead of continuing to fabricate ever more complicated fiction. 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?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D54670