Embedded Project with Remote Toolchain

[peted]

Hi

I have a VisualGDB embedded RISC-V project which is cross-compiling using a GCC toolchain which I downloaded onto windows.  That works fine.

However I now need to port this to a new, bespoke RISC-V ISA which uses a custom version of LLVM toolchain.  But this is only available on Linux.

I would prefer to host this on WSL2 Ubuntu, and would therefore like to be able to configure VisualGDB to be able to use a remote toolchain – but I cannot obviously see a way of doing this.
I can see that I could probably do this for a Linux project, but this is for an embedded platform.

Please advise if there is any way of doing this?  Is it possible without the “Custom” VisualGDB licence (I have the embedded+linux licence only).

Note:
– My VisualGDB project is using MSBuild, I could switch it to CMake if necessary
– I did create a standard Visual Studio (not VisualGDB) simple CMake project and I can execute the build under WSL2 ok this way, but I would prefer to use VisualGDB.
– The new ISA is an extension to RISC-V, I can accept that some things like IntelliSense won’t work properly that is not a problem

Many Thanks
Pete

 

[support]

Hi,

You should be able to get it working by using the 3-machine setup shown here. You would need to import the custom RISC-V toolchains as a Linux-to-Linux cross-toolchain, disable the automatic deployment tests (you can configure to deploy the project to the same machine), and then override the debug setup.

As far as VisualGDB will be concerned, it will be a Linux-to-Linux project with a completely custom deployment and debugging sequence, so IntelliSense, build error messages and everything else related to build will work out-of-the-box.

To get debugging working, you would need to decide where do you want to run OpenOCD (or another similar program) and where to run GDB. E.g. you can add a custom pre-debug action to copy the built executable to the Windows machine, and then run both OpenOCD and GDB there. Or you could run OpenOCD on the Windows machine, and connect the gdb running on the Linux machine to it.

You can find some pointers and examples on this page; if you need further help, please make sure you can debug everything via command line, and share the details about your manual debugging setup, and we will help you configure VisualGDB to replicate it in the IDE.

 

[peted]

Hi

Thanks for the reply.  I have attempted to do as you suggest, but I have hit a few issues.

First, VisualGDB hangs trying to access the filesystem on the WSL2 machine unless I disable my windows defender firewall (both private and public networks).  I have applied the firewall rule from https://visualgdb.com/documentation/wsl2/ ok.  It is strange because if I select the WSL2 distro then VisualGDB can list toolchains there (e.g it finds an install of GCC) but if I select to choose my own toolchain it hangs because of the firewall issue.
– Is there a log file so I can see exactly how visualGDB is trying to access WSL2, e.g which TCP ports to allow?

Secondly, the test of the toolchain fails which is kind of expected.  Is there any way to instruct VisualGDB not to run the checks after you select a toolchain and click “next” in the wizard?

Thirdly, what I want to do is to build on WSL2 but deploy to windows 10, i.e locally where visual studio is running.  I will then run gdb locally on windows 10 along with openocd in order to debug on HW (some of the ISA won’t be supported but it should still allow downloading of applications).
If I choose separate build & deploy machines, VisualGDB seems to want me to choose some Linux machine – I cannot seem to choose the local windows 10 machine.
Is this possible with VisualGDB (with the non-custom version of the product), or is there something I am missing?

Thanks
Pete

[peted]

Hi just to follow up, the firewall issue was not related to VisualGDB.  For some reason adding the inbound rules did not work for me, so I disabled the firewall for public access on the WSL vEthernet only and then it works.  So now I can easily set the necessary toolchain files on WSL2, but still have the other issues I reported.

[support]

Hi,

No problem, please find the answers below:

1. You can use the View->Other Windows->VisualGDB Diagnostics Console window to see the exact low-level commands issued by VisualGDB.
2. You can uncheck the “Automatically test the connection” checkbox at the bottom of the target selection page in the wizard. VisualGDB will still verify that the toolchain works (i.e. produces something), but won’t try to deploy it.
3. You can do that fairly straight-forward with the Custom edition – change the GDB host to Windows, specify OpenOCD as the custom gdb stub, and add a custom pre-debug action that will copy the file (just “cp $(TargetPath) /mnt/c/deployment/dir”). If you are using a lower edition, you can upgrade it here. If you do not want to upgrade, you can create wrapper scripts on the Linux subsystem that would run commands on Windows (e.g. by running an SSH server on Windows) so from the VisualGDB’s point of view, everything still runs on the build machine, but it could be worthwhile to use the Custom edition that was specifically designed to handle such setups.

[Author]

Posts