Does VSLinux work with Armv8 (64bit)

MartynSloss commented 7 years ago

Description I am trying to get Visual Studio Remote GDB Debugger working with nVidia Jetson TX1 Evaluation Board Which uses a 64bit ARM processor (ARMv8 Processor rev 1 (v8l))

Expected results Was expecting code to get copied over and compiled using g++ on remote machine (I have had it working with a DE1-SOC Arm board (ARMv7 Processor rev 0 (v7l))
Actual results Get the following Message: Current project architecture 'ARM' is incompatible with the remote system architecture '' ('Unknown'). Please switch the project architecture to '' in Configuration Manager.

* VC++ version, Visual Studio Community 2015 Hardware Hardware : jetson_tx1 Revision : 0000

Linux system name and version, DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS" NAME="Ubuntu" VERSION="16.04.2 LTS (Xenial Xerus)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 16.04.2 LTS" VERSION_ID="16.04" VERSION_CODENAME=xenial UBUNTU_CODENAME=xenial ARM Processor (x4) model name : ARMv8 Processor rev 1 (v8l) BogoMIPS : 38.40 Features : fp asimd aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x1 CPU part : 0xd07 CPU revision : 1 GCC gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 GDB GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1 host=aarch64-linux-gnu --target=aarch64-linux-gnu

gdbserver GNU gdbserver (GDB) 7.11 CPU arch, aarch64-linux-gnu

I'm guessing I need an ARM-64 description for the configuration manager I tried copying folder C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Application Type\Linux\1.0\Platforms\ARM to C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Application Type\Linux\1.0\Platforms\ARM64 and editing Platform.Default to change

ARM ARM ARM armv7 Thumb arm-linux-gnueabihf

to

ARM64 ARM64 ARM64 ARMv8 Thumb aarch64-linux-gnu

but ARM64 didn't appear in the Platform Configuration Drop down

Any help would be appreciated, other wise I'll have to use Eclipse :( Thanks

stanthomas commented 7 years ago

What does your ARM system report in response the the arch or uname -m command? If you can persuade it to return ARM then VCLinux should be persuaded it's 32-bit ARM and you can supply 64-bit compiler options as required.

MartynSloss commented 7 years ago

Thanks,

That seemed to work making a dummy version of uname that returned ARM worked. It only seems to get called when initially adding the connection under Connection Manager, after that I can change uname back to the original version. Debugging using gdb still doesn't work though. Martyn

On Wed, Mar 1, 2017 at 12:52 AM, stanthomas notifications@github.com wrote:

What does your ARM system report in response the the arch or uname -m command? If you can persuade it to return ARM then VCLinux should be persuaded it's 32-bit ARM and you can supply 64-bit compiler options as required.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Microsoft/VSLinux/issues/110#issuecomment-283210106, or mute the thread https://github.com/notifications/unsubscribe-auth/AFtz7GmV-2rVhF1g1UnMp6DfvgB3Hu3fks5rhMFigaJpZM4MNWWd .

MartynSloss commented 7 years ago

On TX1 ubuntu@tegra-ubuntu:~$ uname -a Linux tegra-ubuntu 3.10.96-tegra #1 SMP PREEMPT Wed Nov 9 19:42:57 PST 2016 aarch64 aarch64 aarch64 GNU/Linux

cat /proc/cpuinfo ubuntu@tegra-ubuntu:~$ cat /proc/cpuinfo processor : 0 model name : ARMv8 Processor rev 1 (v8l) BogoMIPS : 38.40 Features : fp asimd aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x1 CPU part : 0xd07 CPU revision : 1

ubuntu@tegra-ubuntu:~$ gdb --configuration This GDB was configured as follows: configure --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-auto-load-dir=$debugdir:$datadir/auto-load --with-auto-load-safe-path=$debugdir:$datadir/auto-load --with-expat --with-gdb-datadir=/usr/share/gdb (relocatable) --with-jit-reader-dir=/usr/lib/gdb (relocatable) --without-libunwind-ia64 --with-lzma --with-python=/usr (relocatable) --without-guile --with-separate-debug-dir=/usr/lib/debug (relocatable) --with-system-gdbinit=/etc/gdb/gdbinit --without-babeltrace

ubuntu@tegra-ubuntu:~$ gdbserver --version
GNU gdbserver (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public L
This gdbserver was configured as "aarch64-linux-gnu"

robotdad commented 7 years ago

We're looking at how we enable additional platform options so will make sure ARM 64 is part of that list.

Regarding debugging not working have you tried gdb mode in addition to gdbserver?

MartynSloss commented 7 years ago

Great:) gdb mode worked Thanks Martyn

On Thu, Mar 2, 2017 at 5:01 PM, Marc Goodner notifications@github.com wrote:

We're looking at how we enable additional platform options so will make sure ARM 64 is part of that list.

Regarding debugging not working have you tried gdb mode in addition to gdbserver?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Microsoft/VSLinux/issues/110#issuecomment-283712995, or mute the thread https://github.com/notifications/unsubscribe-auth/AFtz7HZFthFQDqTlmH7nwnh3VX40rFmGks5rhvXQgaJpZM4MNWWd .

ghost commented 7 years ago

Is there another way to convince VCLinux that the target architecture is ARM? I will see about temporarily swapping out uname on my dev board, but it would be handy to be able to edit Connection Manager's data store, if I knew where it was and how to edit it.

P.S. For anyone looking to do a quick swap of uname, I used this python script:

#!/usr/bin/python
import string
import sys
import syslog

syslog.syslog('fake_uname args: \'' + string.join(sys.argv, ', ') + '\'')
if '-m' in sys.argv:
    print 'ARM'

jwt27 commented 7 years ago

Just chiming in to say "me too". I'm getting the same error message after upgrading to VS2017: Current project architecture 'x86' is incompatible with the remote system architecture 'x64' ('x64'). Please switch the project architecture to 'x64' in Configuration Manager.
I have a cross compiler set up remotely which VS doesn't know about, so this message is entirely unhelpful.

masschel commented 7 years ago

Hi all, I'm 'stealing' this thread, as it comes close to my issue. I have VS2015, and installed the VSLinux Extension. I'm also using a Jetson TX1 DK, as initiated in this thread. I used the uname trick to 'emulate' ARM, and created a Console App (Linux). I can compile the application, and an executable is successfully created on the device. So far so good.

However, I cannot get the debugger to work. I get a dialog box telling me 'Unable to start debugging. Check your debugger settings and so on...'. I read in the thread that I should switch to dbg mode, but that didn't help, I get the same dialog.

My Linux experience has degraded since a decade, so I'm a bit lost, and any help is welcome. Should I start a dbgserver on the device? Is there a Pre-Launch Command I should use? What Debugger Ports should I use? I tried randomly changing some of these, but more like a chicken without head then really being sure it would lead to a solution.

Looking forward to get this up and running.

Bart

MartynSloss commented 7 years ago

With your project loaded in VS15 select Project (from main Menu) Properties ( from drop down) Then Under Configuration Properties Debugging Set Debugging Mode to gdb

On Mon, Mar 13, 2017 at 11:52 AM, masschel notifications@github.com wrote:

Hi all, I'm 'stealing' this thread, as it comes close to my issue. I have VS2015, and installed the VSLinux Extension. I'm also using a Jetson TX1 DK, as initiated in this thread. I used the uname trick to 'emulate' ARM, and created a Console App (Linux). I can compile the application, and an executable is successfully created on the device. So far so good.

However, I cannot get the debugger to work. I get a dialog box telling me 'Unable to start debugging. Check your debugger settings and so on...'. I read in the thread that I should switch to dbg mode, but that didn't help, I get the same dialog.

My Linux experience has degraded since a decade, so I'm a bit lost, and any help is welcome. Should I start a dbgserver on the device? Is there a Pre-Launch Command I should use? What Debugger Ports should I use? I tried randomly changing some of these, but more like a chicken without head then really being sure it would lead to a solution.

Looking forward to get this up and running.

Bart

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Microsoft/VSLinux/issues/110#issuecomment-286086516, or mute the thread https://github.com/notifications/unsubscribe-auth/AFtz7OEAfoFECUMMsT7mdcopi8fQiD8sks5rlS4JgaJpZM4MNWWd .

masschel commented 7 years ago

Hi Martyn,

Thanks for your prompt reply. However, I already tried that option before, and it gives me that popup. To me it seems the VS is not even trying to connect to the device, it immediately gives me the dialog.

Do I need to run sth on the device, or change something else in the Debugging option pane, like port number? I do can connect to the device, as the compilation works fine.

One thing I noticed that is different to a previous post is when I type gdb --configuration, I get

--host=arm-linux-gnuabihf --target=host=arm-linux-gnuabihf

instead of

--host=aarch64-linux-gnu --target=aarch64-linux-gnu

I also don't see the --without-guile, and I see --with-zlib

Something else I should look at?

stanthomas commented 7 years ago

@masschel - you can't debug a console application in gdb mode because of a known issue #33 and you can't debug ARM64 in gdbserver mode because 64-bit ARM is not supported and 'tricking' VCLinux means it thinks it's talking to a 32-bit application. In gdb mode all the debugging takes place on the Linux remote so if you can run a gdb session for your application via ssh (from another Linux system is easiest) it should work with VCLinux. Your console application can write to STDOUT and its output will be mixed in with the gdb chatter in the output window (i.e. nothing goes to the Linux Console Window) but don't try to read from STDIN or do anything clever like #96

masschel commented 7 years ago

hi stanthomas, thanks for the reply. It seems I was a bit overexcited when I found out about VSLinux, when they told me to develop on the Jetson. I don't want to go back to my VI/Emacs past ;-). I'll try to figure out what you say above, and see if I can make it work.

gusmally commented 7 years ago

@gjkhw thanks for the script. Were you able to run the console application on your ARM board after this? I'm still having issues.

ghost commented 7 years ago

@gusmally - after replacing the uname binary with that script, I am able to create a connection to the 64-bit ARM board. Then I can run on the ARM board if I carefully follow the instructions here: https://github.com/robotdad/LinuxCrossCompile/tree/master/CrossCompileProject

I have not gone back and tried to run that sample since. For now I am using a 32-bit ARM board, and will worry about 64-bit later.

Fladenbrot commented 7 years ago

@MartynSloss How did you get your dummy uname working? Unfortunately, the script from @gjkhw doesn't have any effect on my Nvidia Drive PX (1) with ARM64.

MartynSloss commented 7 years ago

I just made a shell file called 'uname' with the following contents echo ARM

save it then chmod +x uname

type which uname to find where the real uname is then copy it to uname_orig then copy the new uname to that directory

If you then run Visual studio Configuration Manager should find the ARM

I then saved, and copied uname_orig back to uname Hope this helps Martyn

On Tue, Apr 18, 2017 at 2:52 PM, Fladenbrot notifications@github.com wrote:

@MartynSloss https://github.com/MartynSloss How did you get your dummy uname working? Unfortunately, the script from @gjkhw https://github.com/gjkhw doesn't have any effect on my Nvidia Drive PX (1) with ARM64.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/VSLinux/issues/110#issuecomment-294850868, or mute the thread https://github.com/notifications/unsubscribe-auth/AFtz7BUDLGd0pDrW3FtLL5bMBYyJRyTsks5rxMAEgaJpZM4MNWWd .

maxalces commented 7 years ago

I tried the uname fakeout suggested by @MartynSloss, and it kind of worked. When I re-added my Tegra board to the Connection Manager it showed up with its operating system listed as "Ubuntu (ARM)" instead of "Ubuntu (unknown)". So that was progress.

However, when I try to build, I get an error that says "Current project architecture 'ARM' is incompatible with the remote system architecture 'x64' ('x64'). Please switch the project architecture to 'x64' in Configuration Manager." And when I switch to x64 and build I get an error saying "Current project architecture 'x64' is incompatible with the remote system architecture 'ARM' ('ARM'). Please switch the project architecture to 'ARM' in Configuration Manager."

Has anyone else experienced this?

stanthomas commented 7 years ago

@maxalces It sound like either the current, active project is x64 not ARM or you haven't pointed the ARM project at the appropriate Remote Build Machine. Use the VS Configuration Manager to make the Active solution platform=ARM and Active solution configuration=Debug (I assume you want debug). And ensure that Remote Build Machine is set to the IP address of the ARM board in the project settings for ARM platform.

maxalces commented 7 years ago

Thanks @stanthomas, you were totally right. Somehow throughout my debugging process the target server had changed from my Tegra to a cloud-based Linux server I had for testing.

Thanks! And thanks @MartynSloss for your info about uname, that was very helpful.

pmerloti commented 6 years ago

Any update on this?

I was able to deploy to my NVIDIA Jetson TX2 (aaarch64) using the trick @MartynSloss provided, but GDB is not working...

maxalces commented 6 years ago

I actually stopped using this approach because the compiler error messages I was getting in VS were cryptic and unhelpful. So I don't have any wisdom for you, sorry.

itodirel commented 5 years ago

Hi @maxalces @stanthomas @pmerloti @MartynSloss @Fladenbrot we have added ARM64 support, if you installed the latest VS update you will get it

@jwt27 and @gjkhw regarding the architecture check, that is something that can be disabled in the Property Pages

please let me know if there are any issues here, and I'd happily reactivate and look into it, we are trying to get the issue list number down, so tentatively closing

microsoft / VSLinux

Does VSLinux work with Armv8 (64bit) #110