[Lldb-commits] [PATCH] D73206: `DWARFASTParserClang::m_decl_ctx_to_die` `DWARFDIE`->`DIERef` for DWZ

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Jan 24 01:25:03 PST 2020


labath added a comment.

BTW, I am currently trying to clean up the dwo/dwp code, and here (I think) I ran into a very similar problem to what you are encountering.

Dwo units currently contain a backlink to the skeleton unit that uses them, and we have a fairly convoluted system (that's the part I'm trying to clean up) to ensure that each time we are parsing a dwo unit, we are able to go back to the skeleton unit which uses it (and then to a lldb_private::CompileUnit). Now, in principle, there is nothing wrong with that because the skeleton and split units are in a 1:1 relationship. However, the llvm parser does not have such a backlink. And although I don't think it would be unreasonable to have the llvm parser include this backlink, given that the dwz unit cannot make use of that (not 1:1), I think it would be a good idea to come up with a different solution for this, and then have both dwo and dwz use that.

Overall I think the intention of passing another DWARFUnit pointer to identify the "compile unit that we're actually parsing stuff into" is reasonable (as with DWZ, the idea that a DWARFUnit somehow corresponds to an lldb CompileUnit is completely breaking down). But I don't think we should be making that a part of the DWARFDIE (and thereby inflitrating it into everything). Instead I think it should be something on top of that. Whether that needs to be a separate class/struct (std::pair<DWARFUnit, DWARFDIE>?) or just and additional argument to the functions that need it is still not fully clear to me...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73206





More information about the lldb-commits mailing list