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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
