Jupyter Kernel: Launch the debugger with the current triple in REPL mode

Development LLDB
1

The Swift for TensorFlow team has developed a Jupyter kernel for Swift based on the Python LLDB API.

One problem I found while trying it is that modern macOS APIs are unavailable (SR-8371):

In [1]: import Foundation
In [2]: ProcessInfo.processInfo.userName
error: <REPL>:1:25: error: 'userName' is only available on OS X 10.12 or newer

It seems that by default the LLDB target is started with the triple set to x86_64-apple-macosx10.11.0 instead of the current running triple (x86_64-apple-macosx10.14 in my case).

On the other hand, the Swift REPL is executed by default with the current running triple:

$ swift
Welcome to Apple Swift version 4.2 (swiftlang-1000.11.37.1 clang-1000.11.45.1). Type :help for assistance.
  1> import Foundation
  2> ProcessInfo.processInfo.userName
$R0: String = "pvieito"

What LLDB API could I use to have the same behavior on the Kernel code? You can read the current implementation of the LLDB target initialization here.

Something like this works but I don't think it is a clean solution:

target_triple = None

if platform.system() == "Darwin":
    target_triple = "x86_64-apple-macosx" + platform.mac_ver()[0]

self.target = self.debugger.CreateTargetWithFileAndTargetTriple(repl_swift, target_triple)
2

@marcrasi @Jim_Ingham Any idea or suggestion about this?

3

If you take a look at the code in SwiftREPL.cpp in lldb (in SwiftREPL::CreateInstanceFromDebugger) you will see that it does pretty much what you do here, but it uses an API to get the host triple in a generic way. That API (HostOS::GetArchitecture()) isn't available in the SB API's, but it certainly could be added to SBHost. That would clean this up a little bit.

It would also be fine to add an API like CreateTargetWithHostArch that does this for you. But that isn't present currently.

4

Yeah, I agree that's not very robust. Either of Jim's solutions sound cleaner and more robust.

One thing to note is that this problem might eventually go away on its own if I get around to switching the jupyter kernel to use SwiftREPL.cpp as discussed in this thread. All the initialization code in the jupyter kernel will go away and the kernel will instead call into the SwiftREPL.cpp initialization code that already does the right thing with the triple. I don't have any specific plans about when to do this, so it might be a while though.

5

Thanks, I had found REPL.cpp on the LLDB repo, but not SwiftREPL.cpp which seems to contain the biggest part of the initialization logic.

Yes, exposing SwiftREPL class through the Python API would solve a lot of these problems and the duplicate implementations.

In any case, it seems that it is not possible to do it in a clean way right now as the HostOS API is not currently exposed so I'll wait for the SwiftREPL solution :slight_smile:

6

Did you file a bug requesting that we expose something like Debugger::CreateREPLTarget with http://bugs.swift.org? I can't promise I'll have time to get to this soon, but if the bug's there I won't forget and maybe somebody else will see and get to it.

7

Thanks! I have created one report requesting the REPL/SwiftREPL SB API SR-8971 and another one (which could be very useful more generally) for the HostOS APIs SR-8972.