Vscode-cpptools: Add ARM64 support (linux)

[bobbrow]

2497 was opened as a result of missing ARM64 support on linux. Please upvote this issue if you need support for aarch64.

[xueyunquan]

I'd like to support this one. There are more and more aarch64 boards out there which run Desktop GUIs. Direct on-board coding & debugging would be very cool.

[SX-GitHub]

I bet there are more than 25 people desperately want this including myself, but nobody knows a feature request is posted here.

[sean-mcmanus]

@SX-GitHub Yes, that is 100%. We realize that only a small fraction of users will upvote, e.g. our most upvoted feature has only 300 upvotes. This issue is pretty high on the list: https://github.com/microsoft/vscode-cpptools/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc , i.e. the 9th most upvoted for the language service features.

[weizhiyi777]

These days I was working on jetson tx2 board and using vscode to program. So the support of arm64 is also very helpful to me.

[sean-mcmanus]

@bobbrow We seem to have 2 issues tracking "ARM" -- should we consolidate it to 1? I can't tell how the upvotes are for ARM in general or just ARM64, i.e. is this issue a duplicate of https://github.com/microsoft/vscode-cpptools/issues/429 ?

[SX-GitHub]

@sean-mcmanus This shouldn't be considered as duplicated. I've seen too many projects claiming support "ARM" but leave ARM64/AArch64 behind, one of the reasons is Raspberry Pis are so popular (ARMHF which is 32 bit) many developers prioritized ARMHF higher. However, virtually all newer Pi-like SBCs are ARM64, I'm also expecting the overdue Raspberry Pi 4 to be ARM64.

[Souldat]

Just wanted to voice my upvote for this as well. Would be really huge considering the newly added SSH remote debug / development in the latest version of visual studio code for working with systems like the raspberry pi from windows.

[alexdewar]

I would also love to see this, so I can run VS code on my Chromebook.

[alexdewar]

@sean-mcmannus Also, is the source code for the Microsoft.VSCode.CPP.Extension.linux binary available? I wouldn't mind trying to build the binaries for ARM64 myself.

[sean-mcmanus]

@alexdewar The source code is not available -- we don't know yet how much work would be required to build for ARM64 yet.

[alexdewar]

That's a pity. It's great that Microsoft have made VS code open source, but in this case without the source code it means we don't have the option of e.g. making a community build of this plugin. I'd really like to use VS code on my Chromebook but there wouldn't be a lot of point for me without proper C/C++ support.

[RSDuck]

it would be great to have a general ARM64/ARMv8 intellisense mode available on all platforms for cross compiling, additionally to gcc/msvc/clang-x64.

While the x64 mode works mostly, it e.g. reports false errors, when referencing registers in inline assembler.

[TSKangetsu]

really need 😢

[krisklau]

Would be great!

[SergeyIcool]

It will help us a lot!)

[ItaloYeltsin]

Looking forward for this feature!

[EunSungYang]

i want that...

[ldsolano17]

Looking for support as well!

[ChihweiLHBird]

I would like to run VS Code on the surface pro x in the future. ^_^

[Liber-coder]

I very need this feature, and I have been look for it for a long time.

[RongoDog]

This feature would greatly help with the disconnect between Apple and Nvidia... Since we don't have access to Nsight because mom and dad are fighting, we're forced to use raw command line tools to debug on the Jetson line of products. It would be wonderful to have a least gdb debugging and remote development work well through the vscode UI. Other IDEs, such as eclipse don't seem to measure up... Note this also helps those without a graphics card (and therefore CUDA) on their main machine. In fact, Jetson TX2 development board, being ARM based, doesn't even have support for the CUDA Toolkit :(

[marty1885]

Well, bumping the issue again.

I'm running a few AArch64 servers for HPC and a AArch64 workstation. Having IntelliSense on them would be great that I don't have to write code on x86 then copy everything to ARM for testing. Instead I could have my entire workflow on ARM. Otherwise vscode on ARM is quite a good experience.

The same would be for RISC-V and PPC64. PPC64 have already been an established HPC platform and RISC-V is on the horizon. It would be great (at least for the HPC community) to have IntelliSense work on most architectures.

[OscarKro]

I have always used Ubuntu and other operating systems on all sorts of devices. I'm trying a Chromebook right now which has aarch64/arm64 processor. I really need this feature. Any updates on this? I want to use vscode, but not without intellisense for c++.

[abarcovschi]

I also really need this feature. Have been tracking it for a while now and no developments.

[nexusza]

If only I can upvote 1000+. Edge computing becoming a reality. We need this one :)

[raix]

+1 would be great, feeling a bit of pain when doing remote development on the jetson nano. Looking forward to the release of https://github.com/microsoft/vscode-cpptools/pull/5064

[ZgblKylin]

+1
Working on nvidia xavier devices, which is aarch64(arm64). The plugin doesn't work is really a big trouble.

[nexusza]

Is there anyone here that has a temporary alternative yet?

[thymbahutymba]

+1

[Nufflee]

+1

[macdew]

+1 please for aarch64 remote development

[peter-pri]

I am running vscode (1.44) natively on my Jetson Nano.
vscode has some build-in C/C++ support but I need Intellisense also !

[cfriedt]

It gives me the sads ... 😭

[eungiHong]

I am running vscode (1.44) natively on my Jetson Nano.
vscode has some build-in C/C++ support but I need Intellisense also !

How did you run vscode on Jetson Nano? Could you please tell how to do this?
Since C/C++ extension does not surppot ARM64, I can't run debug on cpp files.

[es6rc]

+1 need support for aarch64 development

[nathanrpage97]

@bobbrow Curious Is there a reason this is in milestone 0.30.0 while #429 is in milestone 0.29.0?

[jharmer95]

@bobbrow Curious Is there a reason this is in milestone 0.30.0 while #429 is in milestone 0.29.0?

Well they are different architectures, and the Raspberry Pi (armhf) is probably the most popular ARM computer so in that regard it makes sense that they would want to try it there first and apply what they learned to ARM64
But I'm just guessing, not involved with the project

[wwayland]

+1

[kjnixpark]

+1

[alexdewar]

@jharmer95 In #429 it seems that people are talking about support for ARM CPUs in general, including ARM64 (aka ARMv8), rather than just armhf (ARMv7). ARM64 is used for Raspberry Pi 3 and 4 as well as all recent Chromebooks etc. so if anything I'd imagine that ARM64 support would be the most sensible thing to go for first.

[jharmer95]

@jharmer95 In #429 it seems that people are talking about support for ARM CPUs in general, including ARM64 (aka ARMv8), rather than just armhf (ARMv7). ARM64 is used for Raspberry Pi 3 and 4 as well as all recent Chromebooks etc. so if anything I'd imagine that ARM64 support would be the most sensible thing to go for first.

These devices certainly use ARM64 processors, but all of them you have listed with their default OS are not using aarch64 software because they are actually running a 32-bit kernel and/or userland hence the reason why armhf might be a more desirable target

[alexdewar]

@jharmer95 In #429 it seems that people are talking about support for ARM CPUs in general, including ARM64 (aka ARMv8), rather than just armhf (ARMv7). ARM64 is used for Raspberry Pi 3 and 4 as well as all recent Chromebooks etc. so if anything I'd imagine that ARM64 support would be the most sensible thing to go for first.

These devices certainly use ARM64 processors, but all of them you have listed with their default OS are not using aarch64 software because they are actually running a 32-bit kernel and/or userland hence the reason why armhf might be a more desirable target

Good point.

[sean-mcmanus]

I moved it to 0.29.0. I don't know a reason why the ARM64 support would take longer, but if I find a reason it should be delayed I can move this back.

[burness]

really need

[7oud]

look forward it

[blieusong]

please heeelp. Yes arm64 support for the C/C++ extension would be very nice in my view. Thanks!

[rossburton]

Yes, please. My development environment is a local Macbook with VS Code, doing remote SSH to an arm64 server.

[Jeremaiha-xmetix]

Has anyone been able to run PlatformIO-Arduino with VSCode on Jetson Nano B01 ?

[StevenFrawley]

Need this to develop on both an ARM64 target (Jetson), and for same but remotely from Ubuntu.
Needed to support government work, which I know is sometimes an oxymoron...

[sean-mcmanus]

We built a vsix that just uses our ARM binaries and it works for us when we test on the 64-bit aarch64 Raspberry Pi 4 OS -- does that seem okay or does anyone know if there's a problem that could cause it to not work in some scenarios? We could possibly release that tomorrow if anyone wants to try it earlier.

Also, does anyone really want our processes to use >2-4 GB of memory on their ARM64 devices? Our thought was that would be undesirable anyway in most cases, and on Windows we only publish a 32-bit binary so that it crashes from out of memory instead of using all the memory on the machine in cases where a rare infinite memory "leak" bug is hit.

Our aarch64/ARM64 build is hitting some failure that we're still investigating (might take a few more days).

[hamaney]

@sean-mcmanus In our process we use EC2 ARM instances for debgging/building so memory is not an issue at the development stage.

[sean-mcmanus]

We've added an aarch64 vsix at https://github.com/microsoft/vscode-cpptools/releases/tag/0.30.0-insiders2 . Let us know if anyone encounters any issues with that (particularly since the language service binaries were compiled for 32-bit armhf and not aarch64). One known issue is libtinfo5 needs to be installed for clang-format to run (https://github.com/microsoft/vscode-cpptools/issues/5958).

[7oud]

The aarch64 vsix can not work on Jestson NX, Here are some notifications

Unable to start the C/C++ language server. IntelliSense features will be disabled. Error: Launching server using command /home/xxx/.vscode-server/extensions/ms-vscode.cpptools-0.30.0-insiders2/bin/cpptools failed.

Couldn't start client cpptools

[hamaney]

Notification

Couldn't start client cpptools

Unable to start the C/C++ language server. IntelliSense features will be disabled. 
Error: Launching server using command /home/ubuntu/.vscode-server-insiders/extensions/ms-vscode.cpptools-0.30.0-insiders2/bin/cpptools failed.



md5-1ebbeaa230c808ae77df6d4e72c2805a



[Error - 2:31:15 AM] Starting client failed
Launching server using command 
/home/ubuntu/.vscode-server-insiders/extensions/ms-vscode.cpptools-0.30.0-insiders2/bin/cpptools failed

However, I pressed F5 and it seems to be debugging normally!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! awesome

[sean-mcmanus]

@7oud @hamaney Thanks for letting us know -- we'll continue looking into fixing our build of cpptools/cpptools-srv for the aarch64 target. Yeah, the debugger is arm64-specific already.

[rmurphy-arm]

Note that not all AArch64 kernels will include the compat layer necessary to run 32-bit Arm binaries - I know my usual distro doesn't enable it. Also there are some CPUs out there that have no AArch32 support at all (e.g. Cavium ThunderX), so ultimately you _will_ want a proper native AArch64 build.

[prutschman]

Launching cpptools (from 0.30.0-insiders2) on aarch64 failed for me, but not for the reason I expected.

$ $HOME/.vscode-server/extensions/ms-vscode.cpptools-0.30.0-insiders2/bin/cpptools
-bash: <home>/.vscode-server/extensions/ms-vscode.cpptools-0.30.0-insiders2/bin/cpptools: No such file or directory
$ file <...>cpptools
<...> ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-, for GNU/Linux 3.2.0, BuildID[sha1]=2ca2ba5e900189d2357bc950df7d3b9373690623, not stripped

It looks like something went wrong with the ld-linux path?

If I try invoking it directly with the platform ld-linux, then it of course fails for the expected reason. (And there's no 32-bit userland on this platform, so I can't just invoke the proper ld-linux)

$ /lib/ld-linux-aarch64.so.1 <...> cpptools
<...>/cpptools: error while loading shared libraries: <...>/cpptools: wrong ELF class: ELFCLASS32

[sean-mcmanus]

@prutschman The binary is built for armhf and not aarch64 -- are you saying you think there's a different problem? Good news is we got our aarch64 build fixed, so we should be able to publish a new vsix some time next week.

[prutschman]

Looking forward to the aarch64 build!

It had looked like the embedded ld.so path was truncated, but I've tested a few other binaries on my system that are aarch64 (and load fine) and file also shows the same truncated path on those. So, forget I said anything.

Specifically, I was referring to this part of the output of running file cpptools:
dynamically linked, interpreter /lib/ld-, for GNU/Linux 3.2.0

[cfriedt]

@sean-mcmanus - in general, most Linux distros do not support both armhf and Aarch64 - it's typically one or the other - simply to avoid duplicating libraries (multi-arch). The kernel will usually be compiled to support both executable formats though.

Looking forward to when I can test this out on my Acer Chromebook R13 :-)

Is there a link to official Aarch64 builds for code? I've been using headmelted, but presumably MS will be distributing an official one, no?

[sean-mcmanus]

@cfriedt VS Code for ARM/ARM64 is being tracked by https://github.com/microsoft/vscode/issues/6442 and https://github.com/microsoft/vscode/issues/1031 -- I don't know what their plan is. Currently, our ARM support is only via remoting to an ARM machine from a non-ARM machine, which I suspect is not what most people requesting ARM support want. The headmelted release is currently too out-of-date since our extension requires VS Code version 1.44 or newer, and our license currently prohibits running in headmelted (not sure yet if we should try to update our license, and also our debugger will disable itself).

[alexdewar]

@sean-mcmanus Pleeeeease update the licence :smiley:. VS code having a permissive license means people can do their own thing that upstream might not be interested in (e.g. independently packaging it for a distro) but it's a shame that we can't then use some of these standard extensions with it.

[sean-mcmanus]

We encourage everyone who wants to use our extension with a local ARM64 release of VS Code to upvote https://github.com/microsoft/vscode/issues/6442 . It is currently number 24 on VS Code's list of upvotes and behind releasing for ipad and Windows store.

[sean-mcmanus]

We added aarch64 language service binaries with https://github.com/microsoft/vscode-cpptools/releases/tag/0.30.0-insiders3 . If you have 0.30.0-insiders2, updateChannel set to Insiders, and autoUpdate set to true, it should auto-update.

However, it has a glibc 2.28 minimum dependency, so it will only work on Ubuntu 20 or Debian 10 unless glibc is somehow updated.

Ubuntu 18 (glibc 2.27 minimum) support is planned for 0.30.0-insiders4: https://github.com/microsoft/vscode-cpptools/issues/5993
Ubuntu 16 or Debian 9 support is not currently planned, but you can upvote that at: https://github.com/microsoft/vscode-cpptools/issues/5984

[prashantjain25]

The Code formatting is not working, installed ".vsix" offline.

[sean-mcmanus]

@prashantjain25 You're likely hitting https://github.com/microsoft/vscode-cpptools/issues/5958 . libtinfo5 needs to be installed (as a workaround).

[sean-mcmanus]

Ubuntu 14-18, Debian 8-9, CentOS 7 support got added with https://github.com/microsoft/vscode-cpptools/releases/tag/0.30.0-insiders4 (i.e. glibc 2.17 minimum).

[alexlamfb]

Successfully installed on my arm64 system with the vsix package. It works SO much better than the previous combo of plugins I was using. A+++, would buy again.

[prutschman]

Thank you! Up and running on nvidia linux4tegra on Jetson TX2 now!

[sean-mcmanus]

VS Code ARM64 support is available in the Insiders release at https://github.com/microsoft/vscode/pull/106289#issuecomment-691076575 .