[Lldb-commits] [PATCH] D11119: Parse breakpoint expressions using the language of the frame's CU.
dawn+llvm at burble.org
Tue Jul 14 14:44:48 PDT 2015
dawn added a comment.
Many thanks for taking the time to review! This new language support is painful... I'm grateful you're willing to work with me on it!!
> I would rather see smarts go into Module::PrepareForFunctionNameLookup() and teach it to pull apart names like "ns.foo" and do the right thing. If a string comes into Module::PrepareForFunctionNameLookup() that contains <indentifier>.<indentifier> repeated as many times as needed (<indentifier>.<indentifier>.<indentifier>.<indentifier>) then we should correctly pull those apart and search for "foo" and then match against "ns.foo" (just like Module::PrepareForFunctionNameLookup() takes "ns::foo" and looks up "foo" and then matches agains "ns::foo"). I don't think we need a language indicator to tell us, we should be able to just break it up without that hint.
Currently this "pulling apart" happens via CPPLanguageRuntime. Do you want a version of
CPPLanguageRuntime that handle Pascals as well; a LanguageRuntime::ExtractContextAndIdentifier that is a superset and iterate through that? The problem is that the type mask can come in as eFunctionNameTypeMethod or eFunctionNameTypeBase. What C++ does with this (how it would split it apart) is different from how Pascal would split it. How would you workaround that?
> We could provide a language hint to Module::PrepareForFunctionNameLookup() if we want to and then have the user specify "--language pascal" when doing the "breakpoint set --name ns.foo --language pascal", but we shouldn't be using any frame's compile unit language to do so.
Yes, I plan to add options like this, but wanted to use the frame's CU as the default, just as gdb does. It's a pain for a Pascal user to always have to specify "--language pascal" every time they want to set a breakpoint or evaluate a string. Agreed - using the frame's CU isn't perfect either, but it's the option gdb adopted, so has precedence and years of acceptance.
But I hear you, and will revise this patch to work off an option instead.
I had looked at adding language options settings... getting those options down to the code that needs to check them will change quite a few APIs. I also wasn't sure how best to specify the language - should it be a global setting that breakpoints and evaluation both use, or should each command have a "--language" option?
More information about the lldb-commits