> On Jun 27, 2019, at 3:28 PM, Alex Langford via Phabricator > <revi...@reviews.llvm.org> wrote: > > xiaobai added a comment. > > In D63240#1561531 <https://reviews.llvm.org/D63240#1561531>, @jingham wrote: > >> In D63240#1561488 <https://reviews.llvm.org/D63240#1561488>, @xiaobai wrote: >> >>> @jingham: Okay, so I tried to do what you suggested and that solution >>> doesn't work because of ObjC++. After looking into it, it looks like >>> Variable and Function just ask the CompileUnit for the language type >>> instead of determining it themselves meaning that we determining the >>> Variable's language boils down to asking the CompileUnit for its language. >>> That can probably be improved, but I think that just relying on the >>> SymbolContextScope alone isn't yet sufficient. I think it would be worth it >>> to ask the SymbolContextScope before trying all the loaded language >>> runtimes though. Would you be okay with that solution? >> >> >> That's unfortunate. For ObjC++ CompUnits we should get the language from >> the function name: it's either a C++ mangled name (language => , or an ObjC >> name... > > > I'm going to try to modify `Function::GetLanguage` to see if it can figure > out the language based on the mangled name before it asks the compilation > unit. I think that could potentially solve the issue with ObjC++
Yes, that seems like the right thing to do. Even though you can mix ObjC and C++ in an ObjC++ file, you can't mix the object models so you'll never have a method that is both ObjC & C++. It either dispatches like ObjC or it dispatches like C++... So the runtime gotten from the method you're stopped in's name should be right. Jim > >> One way to solve this would be an ObjC++ language runtime which dispatches >> to the ObjC and C++ ones as is appropriate. I'm not sure whether that would >> always be correct, but it would provide a more explicit way to get this >> right. OTOH, that's a lot more work... > > This could possibly work, but it feels like the wrong abstraction. Creating a > LanguageRuntime for a language with no runtime library to work around the > fact that it uses two runtimes for different languages is just masking the > issue. > >> Is your suggestion to say that if the value IS whitelisted for the >> SymbolContextScope language, then we're done, otherwise we ask all the >> runtimes? > > Yup! I personally don't think that asking every language runtime is that big > of a deal, but I recognize that I could be wrong about that. > >> Asking C, C++ & ObjC in an ObjC++ frame is not really right - it would fail >> my contrived example above - but seems like it has a low probability of >> getting us into trouble. But if you are in a ObjC++ file, you certainly >> don't want to ask the Swift LanguageRuntime whether it whitelists the >> symbol. Those are entirely incompatible languages and you shouldn't be >> asking Swift questions about any C-family language frame. Perhaps a more >> precise version of your suggestion would be that if your SymbolContextScope >> language is a C-family language, we ask all the other C Family language >> runtimes, but not the orthogonal languages. > > This idea isn't super terrible imo, but you're right here: Asking runtimes of > other languages in the same family isn't right even if it has a lower > probability of getting us into trouble. It will work until it doesn't. > > > CHANGES SINCE LAST ACTION > https://reviews.llvm.org/D63240/new/ > > https://reviews.llvm.org/D63240 > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
