The vscode package was split into '@types/vscode' & '@vscode/test-electron', see https://code.visualstudio.com/updates/v1_36#_splitting-vscode-package-into-typesvscode-and-vscodetest

Using '@types/vscode' provides better build compatibility when behind strict corporate firewalls as it does not need to download vscode.d.ts as a separate step.

Create a viewlet to show the registers using something similar to 'info registers'.

This will need work in the cdt-gdb-adapter to provide the information.

Hello,

GDB supports some languages besides than c/cpp. I've tried to add Ada to the language list and it seems the DAP server works.

Would you consider to add other languages to package.json? I can send a PR for Ada or for other languages too.

This would help to check the quality of PRs / commits and also enables users to manually test the results of un-merged PRs, as well as locally using this extension until #40 #42 are solved (and even then as likely not each commit will result in an updated vsix release).

Both the debug adapter protocol (DAP) and the vscode counterpart had different "updates" since this was created.
Things like inline values, set and query memory directly and possibly a lot more are on the table.

The question is: Are there plans to maintain this extension for the future and add those here? If yes it may help to do some planning and creating issues for every feature "missing", so people both know about the state (including "accepts PR", if this is the case) and about the possible changes of those.

Currently cdt-gdb-adapter is published to NPM but not cdt-gdb-vscode

It would be useful for extenders if cdt-gdb-vscode was also published

The cdt-gdb-adapter now has some native code. I don't think this will be a one off as there are some really good native modules out there for things like USB enumeration for finding USB serial devices used for debugging, for example.

node.js generally struggles with native modules and the norm is for modules to be built by the consumer at npm install time using gyp. Electron which usually has a node version different than the one running npm has electron-rebuild to rebuild the native libraries for it's version.

VS Code adds a layer of complexity on top of that as evidence in this issue: microsoft/vscode#658.

And I imagine Theia has a similar issue, though Theia seems to be built for every product that uses it, i.e., you don't just download Theia like you do VS Code. So maybe it has more control.

We also don't want to assume users have native build environments installed on their machines to build these at extension install time (or do we, hopefully not). So how do we deal with this?

The worse case scenario is that we have to build the libraries for every version of VS Code we want to support (and how do we decide) and either bundle them with the extension or have a downloader in the extension to fetch the right one. Yuck. Way open to ideas here.

I pushed 0.0.101 to cdt-gdb-vscode a few days ago but it hasn't shown up on open vsx yet. I am not sure how to give this a kick or who to report this to.

@sdirix, @thegecko, @planger do any of you know how/who to ask to make latest cdt-gdb-vscode show up?

For now I was only able to get the user input properly with the Microsoft C++ extension.

I'm expected to see : Press enter to continue... when the program is started.

No possible interation :

The command line is ok :

ps: I can hit the breakpoints normally.

Hello,

I am trying out the cdt-gdb-vscode extension in eclipse Theia on Windows.
I want to attach to a gdbserver that is already running on localhost.

I tried it with the native-debug extension and it works out of the box (https://open-vsx.org/extension/webfreak/debug).

However using the cdt-gdb-vscode extension I cannot pause the execution of the target and I get no thread name.
My launch configuration looks like the following

{
"name": "Attach to VDK (CDT)",
"type": "gdbtarget",
"request": "attach",
"program": "<path to executable>",
"gdb": "<path to aarch64-linux-gnu-gdb>",
"verbose": "false",
"openGdbConsole": "true",
"target": {
"host": "<host>",
"port": "<port>"
}

The way the debug UI looks like

In the Debug console I can also see messages that indicate success of pausing the main thread:
From client: pause({"threadId":1})
To client: {"seq":0,"type":"response","request_seq":9,"command":"pause","success":true}

However the executable is not suspended, and the UI also does not indicate the target as suspended.

Are there still known limitations or do you have any idea what might be wrongly configured?

Thanks and best regards,
Jan

cdt-gdb-vscode version: 0.0.91
gdb version: GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90

One goal of ours is to provide a more GNU/embedded development friendly extension for VS Code that is developed fully in the open. Many VS Code users are using (and struggling with) Microsoft's extension for C++, cpptools.

To help those users migrate to CDT's extension, we should strive to make it easy to convert launches. In theory, it should be a simple as changing the launch type. We should strive to use the same arguments.

First, find out what the cpptools launch settings are. Then plan how to support them.

The VSCode Memory Inspector is a sister project in CDT Cloud that derives ultimately from an enhancement of the Memory Browser in this repository. Would it make sense to remove the Memory Browser code from this repository and direct users to the Memory Inspector in some way?

@thegecko as a Memory Inspector contributor. @asimgunes as a consumer of the exports here.

Feature Description:

Currently the auto-completion in the console of a cdt-gdb-vscode debug console is just listing found words:

For other language this auto-completion supports variables of the actual scope.

Probably this is a cdt-gdb-vscode? @jonahgraham

Now that we have an incoming Memory Browser that uses vscode's webview API and React, how do we test such a thing?

This would include unit testing the components, testing of the UI while mocking out the back end server (i.e. the extension), and end to end testing in vscode (if that's even possible?)

Right now it defaults to the cwd that gdb is in. Not sure what that is.

I'm testing using two debug launches (Real hardware debugging) in windows, cdt-gdb-vscode v0.0.108 is used. When continuously stepping on one launch, with other launch suspended, the call stack suddenly switches to suspended launch. If I continue stepping, the second launch is being stepped.

This is a wired behavior. Please let me guide on where to be focused to fix the issue.

Note : Issue is not reproducible with local debugging (Tried using amalgamator workspace https://github.com/eclipse-cdt-cloud/cdt-amalgamator )

@jonahgraham @MatthewKhouzam @thegecko @marco-miller

Ever since open-vsx was created we have relied on scripts provided by them to auto-publish this extension. However that takes some control away from us to publish when we want to.

See EclipseFdn/open-vsx.org#2171 for some background.

[Question] :
I try to find a common set of extensions working on VSCode, VSCode Remote and GitPod. I'm interested in C/C++ and Ada development.
Is there any chance to see this extension available on the Microsoft VSCode registry?

Thanks for the extension on GitPod already ! ;)

Download source: https://open-vsx.org/api/eclipse-cdt/cdt-gdb-vscode/0.0.106/file/eclipse-cdt.cdt-gdb-vscode-0.0.106.vsix.
Issue: After having a valid launch.json file and clicking "Start Debugging", something appears under "Threads" but quickly disappears. The debug session doesn't start.

I don't think this was introduced by the change in v0.0.106 - MI parser fix. The last working version we used in our IDE was v0.0.103. So I think the issue might be introduced by the packaging change or some change between v0.0.103 and v0.0.106.

We will be using webpack to bundle the webview contents (React and stuff). Microsoft is really pushing to have extensions themselves also built with webpack. Here is a sample from their samples repo:

https://github.com/Microsoft/vscode-extension-samples/tree/master/webpack-sample

I think it makes sense to play along. It also allows us to have a single build process for all contents of the extension using webpack.

I download this project and run "yarn",but it comes to errors, how can I fix it:

yarn install v1.22.0
[1/5] Validating package.json...
warning [email protected]: The engine "vscode" appears to be invalid.
[2/5] Resolving packages...
[3/5] Fetching packages...
info [email protected]: The platform "win32" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[5/5] Building fresh packages...
[1/2] ⡀ cdt-gdb-adapter
error E:\code\cdt-gdb-vscode\node_modules\cdt-gdb-adapter: Command failed.
Exit code: 1
Command: node-gyp rebuild
Arguments:
Directory: E:\code\cdt-gdb-vscode\node_modules\cdt-gdb-adapter
Output:
E:\code\cdt-gdb-vscode\node_modules\cdt-gdb-adapter>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "" rebuild )
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | win32 | x64
gyp info find Python using Python version 3.7.3 found at "D:\Python3\python.exe"
gyp info find VS using VS2017 (15.5.27130.2024) found at:
gyp info find VS "D:\Microsoft Visual Studio 2017"
gyp info find VS run with --verbose for detailed information
gyp info spawn D:\Python3\python.exe
gyp info spawn args [
gyp info spawn args   'C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\gyp\\gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'msvs',
gyp info spawn args   '-I',
gyp info spawn args   'E:\\code\\cdt-gdb-vscode\\node_modules\\cdt-gdb-adapter\\build\\config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_gyp_dir=C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp',
gyp info spawn args   '-Dmodule_root_dir=E:\\code\\cdt-gdb-vscode\\node_modules\\cdt-gdb-adapter',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'E:\\code\\cdt-gdb-vscode\\node_modules\\cdt-gdb-adapter\\build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
Traceback (most recent call last):
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\gyp_main.py", line 50, in <module>
    sys.exit(gyp.script_main())
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 554, in script_main
    return main(sys.argv[1:])
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 547, in main
    return gyp_main(args)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 523, in gyp_main
    options.duplicate_basename_check)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 139, in Load
    params['parallel'], params['root_targets'])
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\input.py", line 2779, in Load
    variables, includes, depth, check, True)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\input.py", line 391, in LoadTargetBuildFile
    includes, True, check)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\input.py", line 263, in LoadOneBuildFile
    aux_data, includes, check)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\input.py", line 300, in LoadBuildFileIncludesIntoDict
    LoadOneBuildFile(include, data, aux_data, None, False, check),
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\input.py", line 233, in LoadOneBuildFile
    build_file_contents = open(build_file_path, 'rU').read()
UnicodeDecodeError: 'gbk' codec can't decode byte 0xaf in position 2353: illegal multibyte sequence
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\configure.js:351:16)
gyp ERR! stack     at ChildProcess.emit (events.js:321:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
gyp ERR! System Windows_NT 10.0.16299
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd E:\code\cdt-gdb-vscode\node_modules\cdt-gdb-adapter
gyp ERR! node -v v12.16.0
gyp ERR! node-gyp -v v5.0.5
gyp ERR! not ok

When I try to use cdt-gdb-vscode to achieve debugging of cpp files in Theia with GDB, the code doesn't break at breakpoint, the breakpoint is faded and when I hover over a message saying r -break-insert: Unknown option ``-source'' is shown . I use the below Launch.json configuratoin

{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "gdb",
"request": "launch",
"name": "Debug (GDB)",
"program": "${workspaceFolder}\HelloWorld.exe"
}
]
}

Error (On hover near breakpoint):

This doesn't seem to have been published to the main VS Code marketplace, any reason why it shouldn't be?

@marcdumais-work has published this extension in the Open VSX Registry.

The service was recently transferred to the Eclipse Foundation and we want to ensure a seamless transition for our users. To ensure uninterrupted service and more exposure for your extension, I recommend the following.

To the maintainers: If you would like to take over publishing to open-vsx.org, here’s how: https://github.com/eclipse/openvsx/wiki/Publishing-Extensions

Claiming ownership of the namespace for your extension(s). To find out how to do this, see:
https://github.com/eclipse/openvsx/wiki/Namespace-Access
As owner you can add more namespace members (including service accounts) yourself in https://open-vsx.org/user-settings/namespaces. Note that publishing can be done by any contributor to the extension, namely those you add as namespace members once they have signed the Publisher Agreement as well.

Useful links:
Eclipse Publisher Agreement
Eclipse Foundation Open VSX Registry Frequently Asked Questions (FAQ)

More details are in these recent blog posts:
https://blogs.eclipse.org/post/brian-king/open-vsx-registry-under-new-management
https://blogs.eclipse.org/post/brian-king/new-era-open-vsx-registry

Today, there’s growing momentum around open source tools and technologies that support Visual Studio (VS) Code extensions. Leading global organizations are adopting these tools and technologies. This momentum has spurred demand for a marketplace without restrictions and limitations. We hope you join us on this journey as we continue to build the Open VSX community.
We look forward to continued innovation from you in 2021!

This issue is to add front-end support for the work done for eclipse-cdt-cloud/cdt-gdb-adapter#114

Using the React component provided by the cdt-gdb-adapter for memory, create a webview panel to show memory.

I installed cdt-gdb-vscode in VS Code on Windows, and opened a folder in Remote WSL mode. Then start debugging, gdb says ptrace: Operation not permitted. The same warning is shown when I use bash instead. But in bash, debugging session works via sudo gdb attach xxxcommand. So how to launch "sudo gdb" to start debugging? Thanks for replying!

launch.json configurations is:

        {
            "type": "gdb",
            "request": "attach",
            "name": "linux",
            "gdb": "gdb",
            "processId": "${command:askProcessId}",
            "program": "/usr/bin/vi",
            "verbose": "true",
        }

The v0.0.104 version of the extension recently published doesn't work, my guess on quick inspection is this line is wrong:

@colin-grant-work this seems to be a regression due to #96

IIRC to be distributed correctly, this extension will have to be compiled once on each major platform and then somehow uploaded to the VS Code marketplace.

Right now to be able to use it in Theia for instance, I compile it and make a release on a fork.

Was just wondering if there was some kind of publishing made with this package as of now?

This issue can also be used to track this, until the CI is up and running.