Debug symbols

[jmgomez]

Hi,

how one can activate the correct debug symbols?

I have used your task and launch files and also I did added the nim-gdb.py via miDebuggerPath o launch (with MIMode: lldb) but no matter what combinations I try, the symbols looks messed up.

Thanks,
Juan

[quantimnot]

What platform are you on?
I assume you're using the Microsoft debugging extension, because of the the miDebuggerPath option?
Can you post your launch config?

I think setting miDebuggerPath is for the debugger path.
I think MIMode is for telling the extension to launch lldb instead of gdb.

Can you run nim-gdb in a shell?

[quantimnot]

There is a shell script in <nimsrc>/bin called nim-gdb. It wraps the gdb on PATH with a directive to load nim-gdb.py.

[quantimnot]

Also, only native gdb types have a pretty printer. Objects have a pretty printer, but it is commented out in nim-gdb.py. You can uncomment it and then see what happens.

If you decide to try out lldb, then use the pretty printer (limited) from https://github.com/paulnorrie/Nim/blob/devel/tools/nimlldb.py

[jmgomez]

Hey @quantimnot , didnt get the notification. Thanks for getting back to me.

It seems like the problem is with the nim-gdb.exe file that you mentioned (dom96/choosenim#247)

[quantimnot]

@jmgomez Add this to your launch config (replace the PATH_TO_YOUR_NIM_SRC value according to your system):

"setupCommands": [
  {
    "description": "Enable pretty-printing for gdb",
    "text": "-enable-pretty-printing",
    "ignoreFailures": false
  },
  {
    "description": "Nim pretty printer",
    "text": "source PATH_TO_YOUR_NIM_SRC/tools/nim-gdb.py",
    "ignoreFailures": false
  }
]

Keep in mind that the pretty printer currently only supports the default gc. It needs updated for ORC/ARC.

[jmgomez]

@quantimnot unfortunately it keeps the same. I can see well formatted the parameters of a procedure and also its value if they are value types. But refs and everything else is messed up. In strings for example it says:

T15_: Invalid variable Attributes

[quantimnot]

This may be a bug in Microsoft's cpptools extension. That is what you're using to debug with, right? I can't reproduce that message on my system (macos).

Enable logging for that launch profile with:

"logging": {
  "engineLogging": true
}

The logging will go to the Debug Console.

Please make a very simple program. Something like:

proc main(a: string) =
  let b = "b"
  let c = addr b
  echo a & c[] # set breakpoint here
main "a"

Please respond with your versions of vscode, cpptools extension and gdb. And also include the debug console output for debugging the simple program above.

I'm curious if you have the same error message if you try using the 'Native Debug' extension.
Here is a config for it:

{
  "name": "Debug with Native Debug",
  "type": "gdb",
  "autorun": ["source REPLACEME/tools/nim-gdb.py"],
  "request": "launch",
  "target": "${workspaceFolder}/simple.exe",
  "cwd": "${workspaceRoot}"
}

[jmgomez]

If with cpptools you mean the "C/C++ for Visual Studio Code" extension it's 1.7.1 VSCode is on 1.61.2 GDB is 10.2

When using the NativeDebug extension it does not seem to pickup python
Undefined command: "import". Try "help". is what the DebugConsole outputs. If I add python before source, it says
Python scripting is not supported in this copy of GDB.. Do I have to run a different version of GDB?

Everything else in the debug console seems to be fine:

`Running executable

Breakpoint 1, main_main_1 (a=0x7ff601de1490 <TM__V45tF8B8NBcxFcjfe7lhBw_3>) at E:/nimtests/nim-debug-example/main.nim:66
66	  echo a & c[] # set breakpoint here`

[quantimnot]

@jmgomez Hmmm, yeah I think GDB has a configure flag during build for enabling Python support.
You have to add --with-python to the ./configure step when building GDB.
https://sourceware.org/gdb/current/onlinedocs/gdb/Python.html
How did you get your GDB?

[jmgomez]

@quantimnot I have a few (cygwin, clion also install one..) I forced it to use the nimble one to make sure, but it does not seem to have python support neither.
Should it be forced like this, right?

launch.json
"gdbpath": "C:\\Users\\juama\\.nimble\\bin\\gdb",

Will try to find a binary that already has it builtin

[quantimnot]

@jmgomez Yeah, that is how you specify a GDB to use.
The nim-gdb file in the Nim repo is only a shell script wrapper. It just calls the first GDB on PATH and then loads the nim-gdb.py file.

I was writing some updated extensions for both LLDB and GDB in python, but after now realizing that there may be many users with python-less builds, I'm experimenting with a new approach. The vscode debugger extensions work with a text interface to GDB and LLDB called MI. I started writing a wrapper of that interface that will be able to translate/filter the symbols and values. One would call the wrapper instead of GDB or LLDB. I think it will work, but I can't work on it again until Monday. I have too much schoolwork.

[canelhasmateus]

Indeed, i have also run into gdb issues on windows - The default implementation is indeed python-less and i had to go through some hoops to acquire one built with it.

[jmgomez]

@canelhasmateus where did you get it? Do you recall?
@quantimnot sounds good. Im just evaluating Nim for doing a massive binding of a C++ project (UE). There is no scape from Windows

[canelhasmateus]

I can't recall the details, but i do remember going through mingw at some point.
From re-searching the internet , i found this thread , which i believe was the guide to solve the problem, by downloading the unofficial build cited there.

[lihaochen910]

I also encountered the same problem using lldb debugging.
Nim: 1.6.0
VSCode: 1.62.3
cpptools: 1.7.1
llvm: lldb-1300.0.32.4 Swift version 5.5.1-dev
task.json

{
    "label": "Build Debug use nim",
    "type": "shell",
    "windows": {
        "command": "nim c -d:debug --debugger:native -o:NimPlaygroud.exe src/main.nim"
    },
    "osx": {
        "command": "nim",
        "args": [
            "compile",
            "-g",
            "--debugger:native",
            "-o:${workspaceRoot}/NimPlaygroud",
            "${workspaceFolder}/src/main.nim"
        ],
    },
    "group": {
        "kind": "build",
        "isDefault": true
    },
}

launch.json

{
    "name": "Debug with lldb",
    "type": "lldb",
    "request": "launch",
    "preLaunchTask": "Build Debug use nim",
    "preRunCommands": [
        "command script import --allow-reload ${workspaceFolder}/.vscode/nimlldb.py"
    ],
    "program": "${workspaceFolder}/NimPlaygroud",
    "args": [],
    "cwd": "${workspaceFolder}"
}

[quantimnot]

@lihaochen910 The nimlldb.py pretty printer is limited. Also, you are using symbols in a global space which leads to more mangling.

I am working on a general solution to pretty printing for both gdb and lldb, but I've run into a few snags. I'll maybe have something useful in a few weeks depending on other workload.