vscode-csharp: Remote Debugging on Linux ARM not Available

Environment data

Developer machine:

PS D:\somehwere\> dotnet --info
.NET Command Line Tools (2.0.0-preview1-005977)
Product Information:
 Version:            2.0.0-preview1-005977
 Commit SHA-1 hash:  414cab8a0b
Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10240
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0-preview1-005977\
Microsoft .NET Core Shared Framework Host
  Version  : 2.0.0-preview1-002111-00
  Build    : 1ff021936263d492539399688f46fd3827169983

Target machine is an embedded ARM Cortex-A7 - but it will fail on any non-x64 architecture.

    root@colibri-imx7:~# dotnet --info
    Microsoft .NET Core Shared Framework Host
    Version  : 2.0.0-preview2-25407-01
    Build    : 40c565230930ead58a50719c0ec799df77bddee9
    root@colibri-imx7:~# uname -a
    Linux colibri-imx7 4.1.39-2.7.2+gba2f75f #1 SMP Thu Jun 8 14:05:02 CEST 2017 armv7l GNU/Linux

VS Code version: 1.13.0 C# Extension version: 1.10.0

Steps to reproduce

Follow the remote debugging guide: https://github.com/OmniSharp/omnisharp-vscode/wiki/Attaching-to-remote-processes

The critical step is the VSDBG installation on the server.

curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l ~/vsdbg

Expected behavior

An ARM debugger is installed.

Actual behavior

The script fails to determine the RID. It seems only x64 RIDs are supported, I tried to supply several RIDs manually, but the download only works for very few x64 RIDs. My application is successfully targeting -r linux-arm. See https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json for a list of RIDs.

I see that this is the same debugger that Visual Studio 2017 uses and not part of the OmniSharp project. Who is responsible for those mysterious debuggers and why are they built for x64 only? Is it part of an open source project (hope) or closed source (hopeless). Any directions are welcome. Remote debugging is essential for ARM devices!

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 115 (47 by maintainers)

Most upvoted comments

We haven’t yet tried any distro aside from Raspbian, but we have our first beta release up. Instructions for anyone who wants to try it: https://github.com/OmniSharp/omnisharp-vscode/wiki/Remote-Debugging-On-Linux-Arm

gregg-miskelly on Nov 30, 2017

We have updated the aka.ms URL that VS uses to download vsdbg, which includes the fix to detect arm platform. Debugging linux-arm from VS should just work^TM now.

chuckries on Apr 3, 2018

I can report that the remote debbugging works with vscode on a Ubuntu 16.04 x64 development machine. On the development machine dotnet core 2.1 preview1 was installed.

development:~$ dotnet --info
.NET-Befehlszeilentools (2.1.300-preview1-008174)

Product Information:
 Version:            2.1.300-preview1-008174
 Commit SHA-1 hash:  b8df89a54f

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.300-preview1-008174/

Microsoft .NET Core Shared Framework Host

  Version  : 2.1.0-preview1-26216-03
  Build    : f2c3216183d20416568a4bbf5bb7d153e826f153

On the raspi I installed

pi@raspberrypi:~ $ curl -sSL https://aka.ms/getvsdbgshbeta | bash /dev/stdin -r linux-arm -v latest -l ~/vsdbg

Finally, I added ssh-login on the pi and modified the launch.json in vscode as described in the wiki.

I only tested Self Contained Deployment.

markusr on Mar 5, 2018

If we can now attach to process on RPI I’m wondering are there any plans to make VS automatically deploy, run and attach debugger on RPI just like with UWP apps on Windows IoT?

dominikjeske on Dec 8, 2018

End user verified. 😃 I deleted all of the contents of my .vs-debugger directory (after a quick backup of course). Then tried attaching to a process from Visual Studio. The linux-arm debugger was downloaded and process attached.

Good work guys!

Roy

RoySalisbury on Apr 3, 2018

Yes.

gregg-miskelly on Mar 30, 2018

We are getting quite close to releasing an “alpha” version.

A few notes:

Debugging support in .NET Core 2.0 is very busted. So, trying this will require running the target app under one of the daily builds of .NET Core 2.1.
If anyone subscribed to this thread has any feedback on what OS distro/version they would like to use that may be helpful. Thus far we have been using Raspbian 9.

gregg-miskelly on Nov 17, 2017

Hi! Any updates on this? Remote debugging is a must have for embedded devices (we are also using an ARM processor). Is there any way the community (me 😃) can help with this?

tamaskaroly on Nov 16, 2017

Great to hear, definitely looking forward to this!

Am 13.06.2017 6:50 nachm. schrieb “Gregg Miskelly” <notifications@github.com

:

Reopened #1562 https://github.com/OmniSharp/omnisharp-vscode/issues/1562 .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OmniSharp/omnisharp-vscode/issues/1562#event-1121767690, or mute the thread https://github.com/notifications/unsubscribe-auth/ANUK-6gnmXUIff_WmJDEd_EXRuc8LkVCks5sDr3PgaJpZM4N3DMm .

nzain on Jun 13, 2017

@bigdnf I am not aware of plans, but the VS folks would implement such a feature are probably not reading this thread. I might recommend using “Help->Send Feedback->Suggest a feature” from Visual Studio.

gregg-miskelly on Dec 8, 2018

YAY! It works!!!

Yes, it looks as if my debugger install on the RPi3 was corrupted. These are the additional steps I needed to perform to get remote debugging on RPi3 to work:

On the RPi3…

Delete the entire ~/.vs-debugger directory (recursively) rm-rf ~/.vs-debugger
Create a new directory path mkdir .vs-debugger cd .vs-debugger mkdir vs2017u5
Install latest debugger curl -sSL https://aka.ms/getvsdbgshbeta | bash /dev/stdin -r linux-arm -v latest -l ~/.vs-debugger/vs2017u5
Start my app cd ~ cd test ./MyConsoleApp

On the Windows dev box…

Attempt to attach to process on RPi3 box named ./MyConsoleApp NOTE: this will hang for a while and ultimately fail at first attempt. That’s OK because what this does is create the ~/.vs-debugger/GetVsDbg.sh file on the RPi3 box for you. Unfortunately due to the default setting of __SkipDownloads=false within said GetVsDbg.sh file, this also downdates the vsdbg files on the RPi3

On the RPi3…

Edit the ~/.vs-debugger/GetVsDbg.sh file and set __SkipDownloads=true
Install latest debugger (yes, again) curl -sSL https://aka.ms/getvsdbgshbeta | bash /dev/stdin -r linux-arm -v latest -l ~/.vs-debugger/vs2017u5

On the Windows dev box…

Attempt to attach to process on RPi3 box named ./MyConsoleApp
Hope for the best 😃

dknippel on Feb 7, 2018

Yes, ASP.NET Core + RPi 3 is one of the things we tested.

gregg-miskelly on Jan 18, 2018

Initially I was unable to ge thte Visual Studio debugger to attach by selecting the process. However, I figured out what was going on.

Basically, Visual Studio runs the following command on the remote:

GetVsDbg.sh -v vs2017u5 -l “/home/pi/.vs-debugger/vs2017u5” -d vscode

So, we know two things right off. It uses the ‘vscode’ command set and not the ‘mi’ one. And second, it wants the debugger installed in ‘/home/pi/.vs-debugger/vs2017u5’. So, I renamed the existing directory (didn’t want to loose it just in case), and copied over the ~/vsdbg version that was installed for linux-arm.

Then I tried to attach again. Still no go. I then looked at the files. Hmmm… they got updated (or downgraded depending on how you look at it). It seems the the GetVsDbg script will always check to see if it’s the latest version and if not, update itself. Well, the version that it downloads is not for linux-arm and won’t even run. However, there is a switch that can be set to NOT update. So in the script I can changed:

__SkipDownloads=false to __SkipDownloads=true

Then updated my vs2017u5 directory with the latest code again.

Now it works. I can attach the Visual Studio debugger to a running process on the linux box all native.

RoySalisbury on Dec 10, 2017

I’ve managed to get debugging running from VS using these instructions on ubuntu 17.10 on the raspberry pi 2 😄 👍 🙌 💯 🥇.

My first attempts using vs code failed because the process terminated with StackoverflowException after printing Loaded '/home/ubuntu/test/System.Private.CoreLib.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. but updating to a newer runtime and deploying in Debug (instead of Release) configuration made it work!

Suchiman on Dec 1, 2017

Yes, this should work on Pi3s (its one of our test systems in fact).

gregg-miskelly on Nov 30, 2017