On 26/04/2019 19:34, Jim Ingham wrote:
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.
No that part doesn't seem too controversial. My point just was that if
we're going to keep the SBHostOS method working for backwards compat,
then we might as well have it be the only way of retrieving the python
path for now.
OTOH, if you are actually getting to a point where you need to "select"
a script interpreter, then doing this now sounds like a natural step (I
know you want to make the python version selectable at runtime, but I
have no idea how exactly do you intend to achieve that).
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.
I suppose XCode could just launch two lldb binaries instead of one, and
choose the process to host a debug session depending on the requested
python version (?)
pl
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
