[Lldb-commits] [PATCH] D137983: [lldb] Disable looking at pointee types to find synthetic value for non-ObjC

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

We have tests for shared libraries (grep for DYLIB_C(XX)_SOURCES)), but it's easier to reproduce this problem by compiling one CU with -g0 -- see inline comment. (If you are creating an "API" test for this, beware that their default is to build everything with -fstandalone-debug, and you'll need to explicitly change that (see LIMIT_DEBUG_INFO_FLAGS))

This behavior (bug) is triggered by the `FrontEndWantsDereference` formatter flag, which is why it manifests itself for (libc++) vector and friends. The ObjC formatters don't set that flag so they should be safe. The libstdc++ formatters don't set it either. Furthermore there doesn't seem to be a way to set this flag by the user, so it is not possible to create a libc++-independent reproducer (which is what I was going to suggest).

I've been looking for a better way to fix this today (sorry about the delay), but I haven't figured out anything better. There is this fundamental recursion between the pretty printer (which wants to dereference a value) and the dereferencing code (which wants to know if it has a pretty printer -- so it can avoid dereferencing). Just removing the `HasSyntheticValue()`fixed the bug for me -- but then we were able to "dereference" incomplete structs. It's possible we may be able to allow the dereference to succeed here, but then refuse to print the value somewhere down the line. I would like to hear what @jingham things about all this.



================
Comment at: lldb/source/Core/ValueObject.cpp:2676-2677
     if (!m_deref_valobj) {
-      if (HasSyntheticValue()) {
+      // FIXME: C++ stdlib formatters break with incomplete types (e.g.
+      // `std::vector<int> &`). Remove ObjC restriction once that's resolved.
+      if (Language::LanguageIsObjC(GetPreferredDisplayLanguage()) &&
----------------
aeubanks wrote:
> dblaikie wrote:
> > Maybe worth filing a bug and referencing it here?
> > 
> > Is this limitation still necessary if the incomplete type has template parameter DIEs? (I guess probably yes, because it'll be missing member descriptions, etc)
> > 
> > & does this path get hit if the type is declared in one CU but defined in another? (& does the inf recurse/crash loop still get hit in that case, without this patch?)
> > Maybe worth filing a bug and referencing it here?
> Filed https://github.com/llvm/llvm-project/issues/59012, added here
> 
> > Is this limitation still necessary if the incomplete type has template parameter DIEs? (I guess probably yes, because it'll be missing member descriptions, etc)
> yes (I incorrectly mentioned in person that this works with `-gsimple-template-names`, it actually still infinite recurses)
> 
> > & does this path get hit if the type is declared in one CU but defined in another? (& does the inf recurse/crash loop still get hit in that case, without this patch?)
> if the declaration is in a shared library and the main binary has the definition, we hit this
> if we have two CUs, one with a declaration, one with a definition, but both linked into the same binary, we don't hit the issue
> AFAICT lldb restricts looking up debug info to the binary/shared library, but otherwise prefers definitions over declarations?
Yes, but if one of those CUs (the one that was supposed to contain the definition) is built without debug info, then we end up exactly in the same situation (a binary without a definition of a type), but without the complications that shared libraries bring.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137983