[lldb][RFC] add JavaScript as a supported scripting language

[cs01]

#165805 implements support for JavaScript scripting in lldb. Similar to python and lua, it uses swig to generate C++ bindings for the language. V8 is embedded in lldb and used as a JavaScript engine. I am sharing here for discussion to see if there is interest in landing support for JavaScript scripting in lldb. There may be a few gaps in functionality like callback support, but I tried some of the standard scripting bridge functions and they worked.

For build instructions, check out the branch and see the file lldb/docs/use/javascript-reference.md.

To try this out save the following file

/tmp/test.js:

lldb.debugger.SetAsync(false);
let target = lldb.debugger.CreateTarget("/bin/ls");

let breakpoint = target.BreakpointCreateByName("main");
console.log("Breakpoint ID:", breakpoint.GetID());

let error = new lldb.SBError();
let proc = target.Launch(target.GetLaunchInfo(), error);

if (error.Fail()) {
    console.error("Error:", error.GetCString());
} else {
    console.log("PID:", proc.GetProcessID());

    let thread = proc.GetSelectedThread();
    console.log("Thread:", thread.GetThreadID());
    console.log("Stop reason:", thread.GetStopReason());

    console.log("\nStack trace:");
    for (let i = 0; i < Math.min(thread.GetNumFrames(), 4); i++) {
        let frame = thread.GetFrameAtIndex(i);
        let pc = frame.GetPCAddress().GetLoadAddress(target);
        let pcHex = "0x" + (pc >>> 0).toString(16).padStart(8, '0');
        console.log("Frame #" + i + ": " + pcHex);
    }

    console.log("Registers:");
    let frame0 = thread.GetFrameAtIndex(0);
    let gprs = frame0.GetRegisters().GetValueAtIndex(0);

    for (let i = 0; i < Math.min(gprs.GetNumChildren(), 10); i++) {
        let reg = gprs.GetChildAtIndex(i);
        console.log(reg.GetName() + " = " + reg.GetValue());
    }

    proc.Kill();
}

undefined;

then run

./build/bin/lldb -b -o 'settings set script-lang javascript' -o 'command script import /tmp/test.js'

which prints

bin/lldb -b -o 'settings set script-lang javascript' -o 'command script import /tmp/test_process_launch.js'
(lldb) settings set script-lang javascript
(lldb) command script import /tmp/test_process_launch.js
Breakpoint ID: 1
PID: 2351277
Thread: 2351277
Stop reason: 3

Stack trace:
Frame #0: 0x55558d80
Frame #1: 0xf7c2a610
Frame #2: 0xf7c2a6c0
Frame #3: 0x5555ab35

Registers:
rax = 0x0000555555558d80
rbx = 0x0000000000000000
rcx = 0x0000555555574f78
rdx = 0x00007fffffffcbf8
rdi = 0x0000000000000001
rsi = 0x00007fffffffcbe8
rbp = 0x0000000000000001
rsp = 0x00007fffffffcad8
r8 = 0x00007ffff7dfc330
r9 = 0x00007ffff7fcb060
> 

cc @JDevlieghere as we discussed at the LLVM developers' meeting this week

[llvmbot]

@llvm/issue-subscribers-lldb

Author: Chad Smith (cs01)

https://github.com//pull/165805 implements support for JavaScript scripting in lldb. Similar to python and lua, it uses swig to generate C++ bindings for the language. V8 is embedded in lldb and used as a JavaScript engine. I am sharing here for discussion to see if there is interest in landing support for JavaScript scripting in lldb. There may be a few gaps in functionality like callback support, but I tried some of the standard scripting bridge functions and they worked.

For build instructions, check out the branch and see the file lldb/docs/use/javascript-reference.md.

To try this out save the following file

/tmp/test.js:

let dbg = lldb.SBDebugger.Create();
dbg.SetAsync(false);
let target = dbg.CreateTarget("/bin/ls");

let breakpoint = target.BreakpointCreateByName("main");
console.log("Breakpoint ID:", breakpoint.GetID());

let error = new lldb.SBError();
let proc = target.Launch(target.GetLaunchInfo(), error);

if (error.Fail()) {
    console.error("Error:", error.GetCString());
} else {
    console.log("PID:", proc.GetProcessID());

    let thread = proc.GetSelectedThread();
    console.log("Thread:", thread.GetThreadID());
    console.log("Stop reason:", thread.GetStopReason());

    console.log("\nStack trace:");
    for (let i = 0; i < Math.min(thread.GetNumFrames(), 4); i++) {
        let frame = thread.GetFrameAtIndex(i);
        let pc = frame.GetPCAddress().GetLoadAddress(target);
        let pcHex = "0x" + (pc >>> 0).toString(16).padStart(8, '0');
        console.log("Frame #" + i + ": " + pcHex);
    }

    console.log("Registers:");
    let frame0 = thread.GetFrameAtIndex(0);
    let gprs = frame0.GetRegisters().GetValueAtIndex(0);

    for (let i = 0; i < Math.min(gprs.GetNumChildren(), 10); i++) {
        let reg = gprs.GetChildAtIndex(i);
        console.log(reg.GetName() + " = " + reg.GetValue());
    }

    proc.Kill();
}

undefined;

then run

./build/bin/lldb -b -o 'settings set script-lang javascript' -o 'command script import /tmp/test.js'

which prints

bin/lldb -b -o 'settings set script-lang javascript' -o 'command script import /tmp/test_process_launch.js'
(lldb) settings set script-lang javascript
(lldb) command script import /tmp/test_process_launch.js
Breakpoint ID: 1
PID: 2351277
Thread: 2351277
Stop reason: 3

Stack trace:
Frame #<!-- -->0: 0x55558d80
Frame #<!-- -->1: 0xf7c2a610
Frame #<!-- -->2: 0xf7c2a6c0
Frame #<!-- -->3: 0x5555ab35

Registers:
rax = 0x0000555555558d80
rbx = 0x0000000000000000
rcx = 0x0000555555574f78
rdx = 0x00007fffffffcbf8
rdi = 0x0000000000000001
rsi = 0x00007fffffffcbe8
rbp = 0x0000000000000001
rsp = 0x00007fffffffcad8
r8 = 0x00007ffff7dfc330
r9 = 0x00007ffff7fcb060
&gt; 

cc @JDevlieghere as we discussed at the LLVM developers' meeting this week

[DavidSpickett]

I guess the main idea here is it lets V8 users/developers, who are familiar with Javascript, use Javascript to debug V8 and whatever is running in it. I think that's a strong use case.

I didn't look at the changes too closely but I see boilerplate for SWIG and some bits for V8 but nothing that looks to be a burden.

Since this would be opt in, who will be regularly building this configuration? The V8 project itself?

If we wanted to enable this on one of our existing buildbots, are we ok getting a version of V8 from apt or would from source be better? (I know this is covered in the reference doc too but for living at main, maybe you have a different answer)

For build instructions, check out the branch and see the file lldb/docs/use/javascript-reference.md.

At first I thought this was the generated reference pages like we have for Python e.g. https://lldb.llvm.org/python_api/lldb.SBBreakpointList.html.

Beside the point here but would that be useful to do for non-Python languages? We don't do it for LUA, and the Python pages include a lot of C++ type names anyway so it's not like it's totally Pythonic either.

Would Javascript users be fine reading the generated C++ or Python reference?

[JDevlieghere]

I spoke to Chad at the dev meeting. He hacked this up as a hobby project and was showing it to me. I encouraged him to put his work up as a PR to see if anyone else was interested in this.

There's some duplication in the scaffolding but otherwise supporting an additional scripting language is pretty cheap, especially when it's off by default. It's also extremely simple to remove if it's not being used or tested.

We also spoke about defining levels of support for scripting, with Python being tier 1, supporting the embedded interpreter, being imported from an interpreter and supporting all the ScriptedProcess and friends. Lua would be tier 2, supporting the first two but nobody having done a ScriptedProcess in Lua. JavaScript would be tier 3, with only support for the embedded interpreter for now (and maybe it could become Tier 2 if someone wants to use LLDB from Node).

Like the Lua support, I personally think this is a nice to have. With the LLDB DAP extension written in TypeScript, I can imagine attracting more folks that are fluent in that and want to hack around with it.

[DavidSpickett]

I think the ecosystem argument is enough to go ahead with this.

You should try to find at least one place to regularly build this configuration though. I would be ok with enabling it on our AArch64 Linux bot if you don't already have somewhere. For releases:

JavaScript would be tier 3, with only support for the embedded interpreter for now

And therefore dodge the issues that we have with Python.

Not saying we should or not - but it would not be difficult to enable it in LLVM release builds or distro packages, because you don't have to know what V8 is on the system.

We also spoke about defining levels of support for scripting

Once we have 3 we should have some page that mentions the scripting bridges exist. LUA is only mentioned in the build instructions at the moment: https://lldb.llvm.org/search.html?q=lua&check_keywords=yes&area=default

(ofc Python is mentioned all over the place, but people expect Python)