[Lldb-commits] [PATCH] D63240: [Core] Generalize ValueObject::IsRuntimeSupportValue

Greg Clayton via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Wed Jun 26 14:38:38 PDT 2019

clayborg added a comment.

Jim: do you have any other solutions that could make this work?

Comment at: source/Core/ValueObject.cpp:1706-1708
+  for (auto *runtime : process->GetLanguageRuntimes()) {
+    if (runtime->IsWhitelistedRuntimeValue(GetName()))
+      return false;
xiaobai wrote:
> aprantl wrote:
> > clayborg wrote:
> > > aprantl wrote:
> > > > jingham wrote:
> > > > > clayborg wrote:
> > > > > > davide wrote:
> > > > > > > clayborg wrote:
> > > > > > > > Still seems weird that any language can white list a variable by name. Say swift has a variable named "this" which is truly should be hidden and is marked as artificial, we will always show it...
> > > > > > > Swift has no `this`, it has `self`. And yes, there are many places in the debugger where `self` is mentioned explicitly by name and has special handling. Also, I think we want to show it, most of the times.
> > > > > > Exactly Davide. **Any** language can whitelist **any** variable they want for **any** other language regardless of the language of origin of the current ValueObject.
> > > > > I agree with Greg.  Otherwise various languages are going to fight about their respective white lists.  We should really get the ValueObject's runtime language with  ValueObject::GetObjectRuntimeLanguage() and then asking that runtime.
> > > > That's true, but in practice not likely a big problem, since you'd, e.g., need to have an *artificial* variable called `self` in C++ for this to surface.
> > > What variables are we actually trying to not show here? Seems like we mostly want to see the variables, even artificial ones. Does anyone know what the variables that we don't want to see are? And how big of a problem are they?
> > The ones Jim mentioned earlier: Clang injects helper variables for VLA size, Swift injects various kinds of type metadata. We definitely do want to hide them.
> > We should really get the ValueObject's runtime language with ValueObject::GetObjectRuntimeLanguage() and then asking that runtime.
> This isn't going to work though. If you want to know whether you should hide something like `_cmd`, then `GetObjectRuntimeLanguage` is going to give you `eLanguagetypeC`, which has no runtime. If it's marked as artificial, then you'll not see it even though ObjCRuntime whitelists it.
What Alex is saying is the ValueObject figures out its language solely from the TypeSystem type, not from the compile unit language. So we can have C variables in C++, ObjC or ObjC++. That does make it harder.

What we really want to know is if a variable is artificial _and_ a language or language runtime related variable. We seem to want to omit compiler helper variables, but we can't tell the difference. I am find with the current solution for now since there is not easy solution. We can revisit if we need to later.



More information about the lldb-commits mailing list