> On Apr 26, 2019, at 1:29 AM, Pavel Labath via Phabricator > <revi...@reviews.llvm.org> wrote: > > labath added a comment. > > In D61090#1479049 <https://reviews.llvm.org/D61090#1479049>, @jingham wrote: > >> I really thought there was one at the SB layer, because in terms of design >> that is what makes sense. I guess we never really needed it until now, so >> we didn't add it. Once there's more than one hard-coded script interpreter, >> we will need to add some way to select & direct scripts at the various >> script interpreters so we will need SBScriptInterpreter at the SB layer. So >> maybe now is the time to add it in preparation... >> >> Also, the fact that at the lldb_private layer, the ScriptInterpreter is held >> onto by the CommandInterpreter is clearly wrong. The CommandInterpreter >> should have a member that tells it the currently selected ScriptInterpreter, >> but the list of script interpreters should belong to the Debugger. We >> should probably disentangle that at the same time. > > > Yes, it sounds like we should have a SBScriptInterpreter at some point. > Though, right now, it's not really clear to me what will it's exact role be, > so I would tend to agree with Greg that we wait until we have a real use case > for it (so we don't commit to a design we may want to change later).
At this point we could get away with adding is "SBDebugger::GetSelectedScriptInterpreter()" and "SBScriptInterpreter::GetLLDBScriptModulePath" - that would be sufficient to move the responsibility for finding this path to the correct place. Those don't seem controversial to me. I agree sketching in selecting interpreters and invoking scripts on the would not be a good choice till we have something more concrete to play with. > >> As an aside, IIUC, the current work to support either Python flavor only >> supports one interpreter at a time because Python doesn't support loading >> Python 2 & 3 into the same process? > > I've heard someone say that, and I can believe that is the official party > line of the python project, but I haven't investigated how "true" that > statement is. E.g., I'm pretty sure we could get it to work by using some of > the fancier flags of dlopen (RTLD_LOCAL, or the new namespace thingies > present on linux), but that may take more effort than it's worth.. > Interesting. If/when we get to supporting fairly different scripting languages, it will be important to be able to load them all to support "I got cool formatter in scripting language X from person A and another in language Y from person B and I need to use them in the same debugging session". But for now it seems more likely you're either going to convert all your Python scripts from 2 -> 3 or leave them in 2, so this doesn't seem crucial for Python support. The only use-case where this is slightly motivated is apps like Xcode that create many debug sessions in the same lldb binary. This would force them to make a choice of 2 vrs. 3 for all sessions. Jim > > CHANGES SINCE LAST ACTION > https://reviews.llvm.org/D61090/new/ > > https://reviews.llvm.org/D61090 > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
