Kate's GDB plugin provides a simple frontend to any debugger that supports the Debugger Adapter Protocol. In particular, that includes the GNU Project Debugger, aka GDB, as outlined here.

You can enable the GDB plugin in the Plugins section of Kate's configuration.

After these preparations are made, open the source file in Kate, select the "debugger profile", enter the path to the executable in the Settings tab of the Debug View tool view, and select Debug → Start Debugging from the menu to get started.

The "debugger profile" selects the DAP server to use (e.g. GDB) and the way in which to launch this server. A typical case is to have the server launch a process as specified above, but it may also attach to a running process (in which case a PID will have to be specified rather than an executable). There may also be other modes which are specific to the language and DAP server. See also later for additional background and configuration details on this.

All of these options are available in Kate's menus, and many are available on the Debug toolbar as well.

The Debug View tool view consists of several tabs:

The Call Stack tool view contains a list of the formatted backtrace returned from GDB.

The GDB Plugin's Call Stack tool view.

The Locals tool view contains a list of all currently loaded variables from the program and their corresponding values.

The GDB Plugin's Locals tool view.

Special thanks to Google Code-In 2011 participant Martin Gergov for writing much of this section.

The plugin's configuration page defines the "debugger profiles" which can be selected. The default configuration (JSON) is shown there, and it can be "overlayed" by a user provided of similar form. An example excerpt is as follows:

{
    "dap": {
        "debugpy": {
            "url": "https://github.com/microsoft/debugpy",
            "run": {
                "command": ["python", "-m", "debugpy", "--listen", "${#run.port}", "--wait-for-client"],
                "port": 0,
                "supportsSourceRequest": false
            },
            "configurations": {
                "launch": {
                    "commandArgs": ["${file}", "${args|list}"],
                    "request": {
                        "command": "attach",
                        "stopOnEntry": true,
                        "redirectOutput": true
                    }
                },
                "attach": {
                    "commandArgs": ["--pid", "${pid}"],
                    "request": {
                        "command": "attach",
                        "stopOnEntry": true,
                        "redirectOutput": true
                    }
                },
        },
        "gdb": {
            "url": "gdb",
            "run": {
                "command": [
                    "gdb",
                    "-i",
                    "dap"
                ],
                "redirectStderr": true,
                "redirectStdout": true,
                "supportsSourceRequest": true
            },
            "configurations": {
                "launch (debug)": {
                    "request": {
                        "command": "launch",
                        "mode": "debug",
                        "program": "${file}",
                        "args": "${args|list}",
                        "cwd": "${workdir}"
                    }
                }
            }
        }
    }
}

Each of the entries in configurations is combined with the run data and forms a "profile". This specifies the DAP server to launch along with its arguments, where the latter are specific to the profile (commandArgs). The other parts specify the DAP protocol request (launch or attach), along with DAP specific extensions.

Of course, the specified server should be installed (and typically also in PATH for proper execution).

Various stages of override/merge are applied; user configuration (loaded from file) overrides (internal) default configuration, and the "dap" entry in .kateproject project configuration in turn overrides.

{
    // this may also be an array of objects
    "exec": {
        "hostname": "foobar"
        // the command could also be an array of string
        "prefix": "podman exec -i foobarcontainer",
        "mapRemoteRoot": true,
        "pathMappings": [
            // either of the following forms are possible
            // a more automagic alternative exists as well, see referenced section
            [ "/dir/on/host", "/mounted/in/container" ]
            { "localRoot": "/local/dir", "remoteRoot": "/remote/dir" }
        ]
    },
    "dap": {
        "debugpy": {
            "run": {
                // in this section, it applies to all configurations
                // this will match/join with the above object
                "exec": { "hostname": "foobar" },
                // if server is connected to,
                // optionally specify explicit port (which is suitable published/forwarded)
                "port": 5678,
                // the server may then also have to accept more than localhost
                "host": "0.0.0.0"
            }
        }
    }
}