Debugger Support

[ammarahm-ed]

A standard debugger for QuickJS that can work seemlessly with VSCode & Chrome Devtools.

The @openwebf team shared an RFC that links to all existing community efforts to bring this forward:

https://github.com/openwebf/rfc/blob/main/doc/javascript_debugger.md

Most popular QuickJS fork with debugger support

https://github.com/koush/vscode-quickjs-debug

WIP debugger support by @andycall: openwebf/webf#168

[dblnz]

Is this issue up to date?

What do you think about the effort to add the debugger support?

[dblnz]

@saghul Is there any ongoing effort to bring debugger support to quickJs?

[saghul]

Not that I'm aware.

[dblnz]

I've seen some forks that have included debugger support and I wanted to make sure there is no specific reason for which it has not been added to this one.

[saghul]

Last I checked they were unmaintained, is there a recent one?

[dblnz]

From what I've seen, haven't really tried it but looked over the code, the following have debugger support:

• https://github.com/koush/quickjs - unmaintained
• https://github.com/openwebf/quickjs
• https://github.com/bellard/quickjs

[saghul]

From what I've seen, haven't really tried it but looked over the code, the following have debugger support:

* https://github.com/koush/quickjs - unmaintained

* https://github.com/openwebf/quickjs

I don't see it here, can you point out the commit?

* https://github.com/bellard/quickjs

Bellard's repo does not have debugger support.

[dblnz]

You're right, my bad, only koushs fork has.

So, if the support from koush fork were to be ported, assuming everything is done according to the repo's guidelines, would it be accepted?

[saghul]

Last I checked (granted it was a while ago) it was quite invasive so we'd have to look into it. Also the transport for connecting external tools like vscode required blocking calls (IIRC) which we should avoid to make it easier to embedders using event loops to integrate.

[G-Yong]

@saghul How about this? We forked a repository G-Yong/quickjs and added some code to it.
The main goal is to expose the real-time information of the current program (fileName, functionName, lineNum, colNum, opCode) via callback functions in JS_CallInternal, and record some key locations during code interpretation (using emit_source_loc(s)). Then, externally, we build function stacks and other information based on this data.

        {
            if (b && ctx->operation_changed != NULL) {
                int col_num = 0;
                int line_num = -1;
                const char *filename = NULL;
                const char *funcname = NULL;

                uint32_t pc_index = (uint32_t)(pc - b->byte_code_buf);
                if (b->pc2line_buf) {
                    line_num = find_line_num(ctx, b, pc_index, &col_num);
                }
                filename = b->filename  ? JS_AtomToCString(ctx, b->filename)  : NULL;
                funcname = b->func_name ? JS_AtomToCString(ctx, b->func_name) : NULL;

                int ret = 0;
                ret = ctx->operation_changed(*pc, filename, funcname, line_num, col_num, ctx->oc_opaque);
                if (filename) {
                    // fprintf(stderr, "op:%d %d at %s %s:%d:%d\n", *pc, OP_return, funcname, filename, line_num, col_num);
                    JS_FreeCString(ctx, filename);
                    JS_FreeCString(ctx, funcname);
                }

                if(ret != 0)
                {
                    goto exception;
                }
            }
        }

Based on the forked repository, we have basically implemented functions like stepOver, stepInto, and stepOut.
The key is to utilize the real-time information provided by QuickJS to implement these three functions in QScriptEngineAgent: positionChange, functionEntry, and functionExit.
Here is the demo：G-Yong/QuickQtScript

[dblnz]

@saghul How about this? We forked a repository G-Yong/quickjs and added some code to it. The main goal is to expose the real-time information of the current program (fileName, functionName, lineNum, colNum, opCode) via callback functions in JS_CallInternal, and record some key locations during code interpretation (using emit_source_loc(s)). Then, externally, we build function stacks and other information based on this data.

    {
        if (b && ctx->operation_changed != NULL) {
            int col_num = 0;
            int line_num = -1;
            const char *filename = NULL;
            const char *funcname = NULL;

            uint32_t pc_index = (uint32_t)(pc - b->byte_code_buf);
            if (b->pc2line_buf) {
                line_num = find_line_num(ctx, b, pc_index, &col_num);
            }
            filename = b->filename  ? JS_AtomToCString(ctx, b->filename)  : NULL;
            funcname = b->func_name ? JS_AtomToCString(ctx, b->func_name) : NULL;

            int ret = 0;
            ret = ctx->operation_changed(*pc, filename, funcname, line_num, col_num, ctx->oc_opaque);
            if (filename) {
                // fprintf(stderr, "op:%d %d at %s %s:%d:%d\n", *pc, OP_return, funcname, filename, line_num, col_num);
                JS_FreeCString(ctx, filename);
                JS_FreeCString(ctx, funcname);
            }

            if(ret != 0)
            {
                goto exception;
            }
        }
    }

Based on the forked repository, we have basically implemented functions like stepOver, stepInto, and stepOut. The key is to utilize the real-time information provided by QuickJS to implement these three functions in QScriptEngineAgent: positionChange, functionEntry, and functionExit. Here is the demo：G-Yong/QuickQtScript

What is the conclusion on this? Would this be accepted as a solution for debugger support?

[dblnz]

@saghul what is your view on this?