- This topic has 10 replies, 2 voices, and was last updated 3 years, 1 month ago by
.
-
Posts
-
Hello,
I am having trouble cross-compiling for a custom embedded linux device using a yocto sdk installed on WSL, with VisualGDB running on Windows.
<h2>My Setup:</h2>
I’ll break down my setup a bit more:Under VisualGDB Project Properties->Project Settings I have:
- Main build/debug machine set to “Windows 10 Linux Subsystem (Ubuntu)”
- Checked “Deploy executable on different machine (required to debug with gdbserver)”
- Deployment Machine: “root@10.0.0.42”
- The build subsystem is cmake.
- The CMake toolchain is set using “Specify Yocto Environment File…” where I navigate to the yocto sdk in WSL and select “environment-setup-…….-linux” and leave defaults in the following dialog.
<h2>What works:</h2>
Here are is what works:I can right-click on the target in the solution explorer and click on “Open SSH Console for 10.0.0.42” and an ssh console will appear.
I have a simple main.cpp which contains:
#include <stdio.h> int main() { while (1) { for (int i = 0; i < 100; i++) { printf("HI %d", i); } } }I can generate and compile the project correctly.
If I SSH into the embedded linux target, I can see the executable that has been placed onto it and I can even run it and view the output of the above test program.
<h2>The Problem(s):</h2>
The most prevalent one is that VisualStudio locks up after a clicks and has to be restarted, but I am willing to chalk that up to the other issues I am seeing.
<h3>Issue #1</h3>
If I go into solution explorer, and I switch to “Folder View,” then I can navigate to main.cpp in the solution explorer and it will open when I double click on it. It’s path says that it is located at “C:/…./main.cpp” which is what I expect.If I switch to “Solution View” or “CMake Targets View” and try to open or edit main.cpp in a similar way, visual studio locks up and has to be closed using task manager.
<h2>Issue #2</h2>
If I click “Start” without trying to open up main.cpp, it will configure and build correctly as well as transfer the executable to the target but then I get a message whose screenshot is attached.The messages under each tab are as follows:
GDB Session Tab:
VisualGDB is licensed to Noah Meltzer at ******************** ${GDB} --interpreter mi --args "/mnt/c/Users/nmeltzer/Documents/______/Debug/[PROJECTNAME]" Warning: could not set a breakpoint on main. 'Step into new instance' will not work.Exception Details Tab:
VisualGDB version: 5.5.105.4124 ------------------ ef+e1 ------------------ ef+e1: GDB session exited prematurely. Please verify that the project is built, the selected GDB binary exists and the working directory is specified correctly. If GDB reports an internal error, try updating GDB or erasing the target's FLASH memory using external tools. at ef.k3() at kt.f1_2() at VisualGDB.GDBDebugEngine.q(d23 b, w1 a) trace=[ef.k3:7779, kt.f1_2:22, VisualGDB.GDBDebugEngine.q:58]
GDBServer Tab:
sh: xauth: not found Process /tmp/CCCPRemoteTest created; pid = 2637 Listening on port 2000
Other GDBServer Tab?:
sh: xauth: not found Process /tmp/CCCPRemoteTest created; pid = 2637 Listening on port 2000
Thank you for any help! The workflow for this promised by visualgdb would be a great improvement over the current one and there are a few interested parties that may be interested in visualgdb if this works.
Hi,
No problem. If Visual Studio locks up, please try obtaining a stack trace as shown here. If it contains VisualGDBÂ frames, please attach it here along with your VisualGDB build number, and we will investigate further.
The second issue looks like your gdb executable crashes. Please first make sure you can debug your program manually by running gdb manually on the same machine and with the same gdb you are intending to use with VisualGDB. If you can do that without crashing, we can gladly help you configure VisualGDB to replicate the same setup.
If the toolchain appears broken and doesn’t work, we can also gladly investigate it your you and build a custom toolchain that will work with your target. Feel free to reach out to our sales if you would like to get a quote on that.
Ok thanks, I’ll verify gdb is running correctly aside from VisualGDB.
In the meantime, I also generated a call stack trace that shows the lockup error I described (see attached file). I am using VisualGDB version 5.5R5 (build 4124) with visual studio 2019 version 16.11.3. Hope this helps
I was able to debug the target over the command line by running
gdbserver localhost:8000 tmp/on the target embedded linux device and
$GDB [pathto]/on WSL. Doing this, I was able to set a breakpoint at main, and continue. The program would then break properly at main.
However, VisualGDB still fails to debug or set breakpoints. It appears VisualGDB is executing similar commands to those above, using the same GDB and GDBServer that I am running manually on the command line. Attached are screenshots of the VisualGDB diagnostic window, and of the manually-debugged target on the command line.
Thank you again for the help, I hope this thread is useful to others who are experiencing similar issues.
If it helps, when I go into “Advanced GDB Settings”->”Diagnostics” and check “Save all low-level interaction with GDB to ******Test.log, the only line in that file after the gdb error is:
${GDB} --interpreter mi --args "/mnt/c/Users/nmeltzer/<path to target>/*********Test"Which I can paste into WSL and it runs without issue. So this appears to be a VisualGDB bug.
Thanks for the detailed description. This looks like an issue with the environment variable expansion that was fixed in VisualGDB 5.6.
The stack trace looks like VisualGDB is trying to read the contents of one of the source files on the remote machine. It could freeze VS if the project contained files called aux.c or com[1-4].c, although VisualGDB 5.6 contains a check for this. Either way, please try updating to the latest Beta (or VisualGDB-5.6.5.4391.msi) and let us know if the problem persists.
Ok, I updated to the beta you recommended.
If I set up the project to “Store files on localhost-lxss and access them over the network (recommended)”, then VisualStudio/VisualGDB does not load the contents of the file in the editor when I try to open it (see attached image). Since this process should be independent of the actual debug target, I believe VisualGDB may still be the culprit here. That being said, it does not lock up anymore.
However, if I set up the project and use “Setup shared mount point manually”, then everything seems to work.
Thank you!
This could be related to a VS MEF cache bug. Please try restarting Visual Studio. If it doesn’t help, please try right-clicking on the tab header of the source file that is not loading, and select “copy full path”. Please share the full path here, and we will help you get it working.
Ok, Here is the full path:
vgdb-lxss:///mnt/c/****/***/****/***/RemoteTest2/RemoteTest2/Source/main.cppRestarting Visual Studio did solve the error, neither did creating a new project.
Sorry, I typed that restarting Visual Studio “did” solve the error, when I meant to type “didn’t”. So, to be clear, restarting VisualStudio did NOT solve the error.
Thank you
Hi,
Strange. Normally, the WSL projects should use a different type of path mapping and should not allow selecting the incorrect one in the first place. Please double-check that you select the WSL radio button on the target selection page of the wizard, rather than selecting a generic “Build on Linux” option and picking WSL in it. This helps ensure that the correct path mappings are set.
- You must be logged in to reply to this topic.