[Lldb-commits] [PATCH] D53530: Fix (and improve) the support for C99 variable length array types

Greg Clayton via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Tue Oct 23 09:21:31 PDT 2018


clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

Parsing a type shouldn't need an execution context and we shouldn't be re-parsing a type over and over for each frame. We should be encoding the array expression somewhere that we can access it when we need to get the number of children using the current execution context.

The way I would prefer to see this:

- Revert all SymbolFile changes that added an execution context to type parsing
- Change the type parsing logic in SymbolFileDWARF to store the array count expression in some format that is associated with the clang opaque type (clang type metadata maybe?).
- Change "virtual uint32_t TypeSystem::GetNumChildren(...);" and "virtual CompilerType TypeSystem::GetChildCompilerTypeAtIndex(...);" to take an execution context that defaults to nothing like you did with the type parsing in the first patch. This execution context can be used to evaluate the count expression as needed. We can attempt to grab the count expression from the clang opaque type that we stored in the above step, and if one exists, use the current frame to evaluate it correctly.





================
Comment at: source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp:213-229
+  // Handle variables with incomplete array types.
+  auto *type = in_value.GetCompilerType().GetOpaqueQualType();
+  auto qual_type = clang::QualType::getFromOpaquePtr(type).getCanonicalType();
+  if (qual_type->getTypeClass() == clang::Type::IncompleteArray) {
+    if (auto variable = in_value.GetVariable()) {
+      auto *lldb_type = variable->GetType();
+      auto *symbol_file = lldb_type->GetSymbolFile();
----------------
We must abstract this via the TypeSystem stuff and make this happen via the CompilerType interface. What happens when "in_value" is a swift type or other type from the type system? Crash


https://reviews.llvm.org/D53530





More information about the lldb-commits mailing list