Open AbleBacon opened 1 year ago
I'm unable to reproduce this with Ubuntu 23.04:
gcc (Ubuntu 12.2.0-17ubuntu1) 12.2.0
GNU gdb (Ubuntu 13.1-2ubuntu2) 13.1
I am also unable to reproduce this at MSYS2 on Windows (MinGW64) with C:\msys64\usr\bin
in my path.
gcc (GCC) 11.3.0
GNU gdb (GDB) 13.1
My VS Code is set up to use MSYS2 as the shell instead of PowerShell--does the debugger require a certain shell to be used?
On Windows we expect Powershell or Cmd because if you are in the MSYS2 shell, you may not have access to the %USERPROFILE%.vscode folder which contains the extension and its additional tooling needed for it.
In that case, I think that it would be prudent to emit an error message specific to these circumstances, because there's a substantial body of users on places like StackOverflow who have unsuccessfully attempted to troubleshoot this issue, unaware of the fact that this configuration is not supported.
I'm getting the same error-code when trying to cross-debug with a yocto generated SDK (for Windows). The strange thing is, that it sometimes (on some other machines) suddenly works, and I couldn't tackle it down over one year now, why. Any other ideas or has it in the meantime be fixed?
Ok, now I've tried to run the gdb.exe from the commandline and not from within VsCode and I get this error-message: Sorry, it's in german, but it says that python27.dll couldn't be found and re-installation of python could eventually solve the issue. I will check it and come back.
Ok this didn't help to install the latest version of python2 (.7.18).
It's been the case since about version 9.? of GDB that the MI debugger engine does not work with GDB. I believe that this is because the debugger engine is expecting the wrong output from GDB, but there are numerous posts about this on sites like StackOverflow, and the only solution people have found is to downgrade their version of GDB.
The error from this is:
I mentioned this previously here: https://github.com/microsoft/vscode-cpptools/issues/7706#issuecomment-1111801531
I'm attaching the debugger output with
engineLogging
andtraceResponse
enabled, but ultimately I'd suggest simply trying to use the debugging engine with GDB withexternalConsole
set tofalse
and seeing for yourself. The debugger runs normally until the debugging engine gives up on it because of a perceived invalid output.Versions I'm using:
debugger_output.txt