Windows: debugger not found on MinGW

[paul-reilly]

Describe the bug

When attempting to debug a program using the xmake Debug button in the VS Code extension, we get an error message popup.

Error output

Unable to start debugging. Launch options string provided by the project system is invalid. Unable to determine path to debugger. Please specify the “MIDebuggerPath” option.

Info

The line that is causing the issue is:

https://github.com/xmake-io/xmake-vscode/blob/master/src/debugger.ts#L116

Putting the full path to gdb.exe in that field, eg:

miDebuggerPath: "C:/dev/msys64/mingw64/bin/gdb.exe",

... fixes it.

I do not know at this stage how to get the MinGW root from xmake in this extension so that we can append /bin/gdb.exe to it.

---

• xmake vscode version: 1.4.3
• os: Win10
• target platform: MinGW

[waruqi]

You can pass your miDebuggerPath to xmake.customDebugConfig.

"customDebugConfig": {
   "miDebuggerPath": "C:/dev/msys64/mingw64/bin/gdb.exe"
}

We can also improve xmake-vscode to detect it, but I have not msys/mingw environment to test it now.

[paul-reilly]

Aaah, that works - thanks! I can build and test any changes here if you want.

[waruqi]

Can you try running xmake l lib.detect.find_tool gdb and let me see the result?

If it works, then I will use find_tool to find gdb in vscode plugin.

[paul-reilly]

Run under MSYS2/mingw64 shell:

{
  program = "gdb",
  name = "gdb"
}

No output when run under Windows. I do not have a standard Windows install of MinGW though.

[waruqi]

Does it work If I only set gdb to customDebugConfig? Must be the full path?

"customDebugConfig": {
   "miDebuggerPath": "gdb"
}

[paul-reilly]

Just gdb does not work, unfortunately. It must be the full path.

[waruqi]

Got it.

[waruqi]

Can you try running the following commands and let me see the result? I need find full path of gdb on msys2/mingw.

$ xmake lua
> find_tool = import("lib.detect.find_tool")
> find_tool("gdb", {norun = true})

[paul-reilly]

No problem.

• There is no output in either Windows or msys2/mingw.

Here's an example, where I check for cmake at the end, just to make sure nothing is broken:

➜  ft xmake lua
xmake> find_tool = import("lib.detect.find_tool")
xmake> find_tool("gdb", { norun = true })
xmake> find_tool("cmake", { norun = true })
< {
    program = "cmake",
    name = "cmake"
  }
xmake>

[waruqi]

Can you try running xmake l /yourdir/xxx/find_gdb.lua?

find_gdb.lua

import("lib.detect.find_tool")

function main ()
    local paths = {}
    local mingw_prefix = os.getenv("MINGW_PREFIX")
    if mingw_prefix then
        table.insert(paths, path.join(mingw_prefix, "bin"))
    end
    local gdb = find_tool("gdb", {norun = true, paths = paths})
    print(gdb)
end

[paul-reilly]

Yes, that's it. It works on Windows and msys2/mingw if we change the find_tool line to:

local gdb = find_tool("gdb.exe", {norun = true, paths = paths})

Output:

➜  ft xmake l .\find_gdb.lua
{
  program = "C:\dev\msys64\mingw64\bin\gdb.exe",
  name = "gdb"
}

Woot! :)

[waruqi]

Ok, I will improve it in xmake-vscode. thanks~

[waruqi]

I have improved it on dev branch. But I haven't test it.

[paul-reilly]

Unfortunately it is not working. Under the debugger I see that the find_gdb.lua script is returning/printing "gdb".

Here's something interesting under a MSYS2 shell. caprice32 is a mingw project, the one I am testing with, I ran config just to show that this is the current platform:

dev>:/c/dev/caprice32$ xmake f -p mingw
dev>:/c/dev/caprice32$ xmake l /c/dev/xmake-vscode/assets/find_gdb.lua
gdb
dev>:/c/dev/caprice32$ cd ..
dev>:/c/dev$ xmake l /c/dev/xmake-vscode/assets/find_gdb.lua
C:\dev\msys64\mingw64\bin\gdb
dev>:/c/dev$

The directory dev does not have an xmake.lua file in it.

[waruqi]

please add -c to xmake f to clean configuration cache

caprice32$ xmake f -p mingw -c

[paul-reilly]

Progress! Now it returns the full path (see below) and it works after I appended .exe to the return/print statement at the end of find_gdb.lua.

However, I am finding that I have to run xmake f -p mingw -m debug -c at different times for the script to return a path, as we saw in the previous post. I am then running into an issue where:

Side issue

Cannot run xmake config from plain Windows terminal when a mingw project uses pacman packages

---

So I have changed the find_gdb.lua script to use the xmake find_mingw logic, which works reliably. I don't know if there's a situation I haven't thought of where this would be a bad idea:

import("detect.sdks.find_mingw")
import("lib.detect.find_tool")

function main ()
    local paths = {}
    local mingw = find_mingw()
    if mingw and mingw.bindir then
        table.insert(paths, mingw.bindir)
    end
    local gdb = find_tool("gdb", {norun = true, paths = paths})
    if gdb and gdb.program then
        print(gdb.program .. ".exe")
    end
end

[waruqi]

So I have changed the find_gdb.lua script to use the xmake find_mingw logic, which works reliably. I don't know if there's a situation I haven't thought of where this would be a bad idea:

We also need to consider finding gdb on linux and macos. Try this?

import("detect.sdks.find_mingw")
import("lib.detect.find_tool")

function main ()
    local paths = {}
    if is_host("windows") then
        local mingw = find_mingw()
        if mingw and mingw.bindir then
            table.insert(paths, mingw.bindir)
        end
    end
    local gdb = find_tool("gdb", {norun = true, paths = paths})
    if gdb and gdb.program then
        local program = gdb.program
        if is_host("windows") and not program:endswith(".exe") then
            program = program .. ".exe"
        end
        if os.isfile(program) then
            print(program)
        end
    end
end

[paul-reilly]

Oh yes, the function is called for the other OSes now too. Yes, I confirm that the function works in msys2/mingw and standard Windows and that debugging works in VS Code.

Cheers!

[waruqi]

I have updated code and xmake-vscode plugin on market.