[Noah]

Perfect, thank you!

[Noah]

I have tried this on two different machines with the same behavior.

I have attached the generated toolchain file.

On line 55 of the toolchain file, it includes root.cmake which is a file located in C:\Program Files (x86)\Sysprogs\VisualGDB\CMake\embedded. This root.cmake file adds the unwanted compile flags on line 12.

 

• This reply was modified 2 weeks, 2 days ago by Noah.

Attachments:

You must be logged in to view attached files.

[Noah]

Thanks for the response. I tried two different workarounds:

• I added an empty “nulltoolchain.cmake” file and pointed VisualGDB at it using the “Use Existing Toolchain” setting.
• I tried your suggestion of changing the DisableToolchainFile field in the project file.

Both of these worked.

I do not have an existing toolchain file that is meaningful (hence the reason for not pointing VisualGDB at it in the first place). The toolchain file is handled by Zephyr as part of the build system.

I think automatic handling of the toolchain file should be opt-in only since it adds build flags in an opaque way. If this is not possible, then there should at least be a way to disable automatic handling of the toolchain file via the UI, perhaps in the form of a checkbox under “Use Existing Toolchain File.”

[Noah]

Thanks for taking a look. The problem is that if I check “use existing CMAKE_TOOLCHAIN_FILE” and put a null value in (empty string) then VisualGDB still generates its own toolchain.cmake file.

I’ll try adding an empty toolchain.cmake file to see if that works.

[Noah]

Hello,

No problem, It is very possible this is user error.

I have reproduced this on an extremely simple new project created from scratch. The step by step screenshots are shared in the attached .pdf.

This project consists of 3 files:

• CMakeLists.txt
• toolchain.cmake
• main.cpp

Attachments:

You must be logged in to view attached files.

[Noah]

Ok thank you, I followed the guide to export the build command line.

I agree that VisualGDB shouldn’t change any flags, however it really does seem like it is. This specific CMAKE_TOOLCHAIN_FILE issue has been a problem for me in the past and I have found ways to work around it or I would supply my own toolchain file in the project settings.

I exported the build command that VisualGDB is using and it is adding the following flags to the CMake configuration step (note that I redacted some full paths for privacy):

-DCMAKE_BUILD_TYPE=DEBUG -DTOOLCHAIN_ROOT=c:/sysgcc/arm-eabi -DCMAKE_MAKE_PROGRAM="C:/Program Files (x86)/Sysprogs/VisualGDB/ninja.exe" -DCMAKE_TOOLCHAIN_FILE=x:\[...]\..\..\../build/VisualGDB/Debug/toolchain.cmake -DPLATFORM=VisualGDB -DLOCALAPPDATA=C:/Users/[...]/AppData/Local

I have marked the options that I believe could cause problems. You can see from my “project_settings.png” image in the post above that I am not adding any of these options via the VisualGDB project settings, so I really don’t know where they are coming from.

 

Thanks,

Noah

[Noah]

Thank you for the quick responses.

It’s not an nRF project, it’s an NXP i.MXRT running Zephyr. The VisualGDB project itself is a custom CMake project.

Please see “project_settings.png”

Attachments:

You must be logged in to view attached files.

[Noah]

It looks like VisualGDB has some special CMake stuff going on. I compared my build.ninja files from the VisualGDB build and the command line build. I found that the VisualGDB build somehow builds with the -g3 -O0 flags while my command line build does not. I tracked this down to a line in C:\Program Files (x86)\Sysprogs\VisualGDB\CMake\embedded\root.cmake that is shown in “AddedFlags.png” where these flags are unconditionally added if the underlying compiler is GCC. I’m not sure if this is the root issue, but it is definitely a problem. I am intentionally leaving my CMAKE_TOOLCHAIN_FILE unset because the ZephyrOS build system takes care of the toolchain file at a later stage. I see that in this case, VisualGDB detects this unset variable and gives CMAKE_TOOLCHAIN_FILE a value (see “vgdb_toolchain_file.png”).

I cannot find a setting to tell VisualGDB not to assign its own value to the CMAKE_TOOLCHAIN_FILE variable.

Thank you again for your time,

Noah

Attachments:

You must be logged in to view attached files.

[Noah]

I should note that I am using VisualGDB Custom Edition, Version 6.0 (build 5147) with Visual Studio Professional 2022 (64-Bit) Version 17.8.5

[Noah]

Ok, thanks for the response. I should clarify a bit more: I’m seeing a few problems that are maybe related. I’ll go through the steps to produce what I am seeing and what I expect.

Debug Configuration

If I select the Debug configuration in VisualGDB and press Start then everything works and debugs normally.

Release Configuration

When I switch to the Release configuration using the dropdown menu in the toolbar, a few things happen.

The first notable thing is an exception traceback that shows up in the “VisualGDB Build” tab. It starts off "CMake Error: CMake server mode has been removed in favor of the file-api." and then prints a traceback (see CMakeErrorTraceback.png). Doing a “Clean and Reconfigure CMake Project” produces an error that says “The operation has timed out.”

Deleting the build/ directory and retrying does not help.

I can do a clean rebuild and the configure and build steps will both succeed; although the solution explorer will still display the project as having failed to configure.

To get past this for now, I do a clean rebuild and then click “Start.”

I then get an error that VisualGDB failed to start the debug session because it could not find the image in build/VisualGDB/Debug/DEBUG (See IncorrectImagePath.png).

This debug folder does not exist, nor should it. Instead Release builds are located in build/VisualGDB/Release/RELEASE. It seems like VisualGDB should be looking in the Release directory tree for the image, if that’s where CMake is putting the output executable.

The CMake Binary directory is also correct (see BinaryDirectory.png), I would have thought that VisualGDB would use the ${CMAKE_BINARY_DIR} variable to determine where the executable is placed.

Thank you for the help,

Noah

Attachments:

You must be logged in to view attached files.

[Noah]

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

[Noah]

Ok, Here is the full path:

vgdb-lxss:///mnt/c/****/***/****/***/RemoteTest2/RemoteTest2/Source/main.cpp

Restarting Visual Studio did solve the error, neither did creating a new project.

[Noah]

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 reply was modified 2 years, 6 months ago by Noah.
• This reply was modified 2 years, 6 months ago by Noah.
• This reply was modified 2 years, 6 months ago by Noah.

Attachments:

You must be logged in to view attached files.

[Noah]

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.

• This reply was modified 2 years, 6 months ago by Noah.

[Noah]

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.

• This reply was modified 2 years, 6 months ago by Noah.

Attachments:

You must be logged in to view attached files.

[Author]

Posts