Does anyone have experience debugging runtime loadable extension using GDB in VS Code? The extension shall be loaded in the shell using ".load ./shared_file".

I am just using printf() and it is slow and painful. It would also be a way to trace the execution of sqlite3 and to see how extensions work. e.g. Dbstat Virtual Table

Some detail instructions would greatly help me along.

Thanks.

I should have been more clear about how to make this work. You can use the SQLITE_EXTRA_INIT compiler define to set an init function that then calls the sqlite3_auto_extension() function to register your module.

So the stub functions look something like this:

int auto_extension_init(sqlite3* db, const char** errmsg,
    const struct sqlite3_api_routines* api) {
    return sqlite3_extension_init(db, errmsg, api);  /* entry point of your module */
}

int extra_init(const char* unused) {
    return sqlite3_auto_extension(auto_extension_init);
}

And when you build SQLite, you need to include the define: -DSQLITE_EXTRA_INIT=extra_init

The extra_init() function will be called every time the SQLite library is initialized (in the CLI shell or in another application), which in turn will register the given module(s) to be included in each new database connection.

This is an easy way to take the source of a loadable module, and use it as a static extension, without altering the code of the extension (or using some #define to alter the entry method), and without altering the source to SQLite.

I'm answering only for debugging loadable (and loaded) extensions using gdb because that's much less agonizing than "edit, build and examine printf() output" cycles, and probably can be made to work with VS Code if that is actually helpful.

On Windows, an easier debug method is to set an environment variable named "SQLITE_DEBUG_BREAK" before invoking the shell with -cmd ".load ./your_extension.dll" . Then, you can use Visual Studio's just-in-time debugging feature to auto-attach to the process, then set a breakpoint within the implementation of the .load command or anywhere after it runs if the initialization code is not in need of debugging.

The same environment variable can be used to get the shell process suspended while you attach gdb to it, if you disdain learning how to tell gdb what the debugee invocation is to be. It is pretty easy to lookup how to start gdb and make it load your program, and there is a huge advantage to that because it is then easy to restart the whole process, perhaps after an edit and rebuild.

You will still want to set a breakpoint in the extension code after it is loaded. (Otherwise, gdb will lack the information needed to set it.)

Cheat-sheets are pretty easy to find for gdb, and are such a necessity for serious early use of the tool that I am disinclined to look at mine so that I can provide keystroke-level guidance.

(Amended via edit:) None of this is to gainsay Jay's advice.

Thanks folks for your replies. I will try it out.

If anyone you can think of other approaches, do add to this thread.

Thanks again.