[Noah]

Hello,

I will give that a try, thank you.

You mentioned the fix would be to understand why the .Net framework behaves the way it does, and I agree. Of course, I don’t know about how VisualGDB is built, so the following suggestion is a shot in the dark:

Depending on the version of .NET that visualgdb uses, long path awareness may need to be enabled using the application manifest:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
</windowsSettings>
</application>

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#application-manifest-updates-to-declare-long-path-capability

CopyFileW is listed as one function that has a MAX_PATH restriction unless the above is in the application manifest.

Another possibility is that VisualGDB is running into this issue: https://developercommunity.visualstudio.com/t/long-path-support-in-netframework-472-and-windows/1057100

In which case, the solution is listed here: https://learn.microsoft.com/en-us/archive/blogs/jeremykuhne/net-4-6-2-and-long-paths-on-windows-10#configuring-asimple-long-path-net-console-app

 

Best,
Noah

[Noah]

Thanks for the response. Unfortunately, changing to server mode causes an intermittent failure shown in the attachment.

To your point about convincing CMake to make a change to their code model file naming scheme: I don’ t think that will get much traction because

1. My root CMakeLists file is as close to the root directory as possible. One could easily cause a path length over 260 characters by embedding my root source location deeper in the file system, which would cause this error regardless of the length of the code model cache file names. CMake’s solution to long path length errors on windows is to enable long file name support, and this works perfectly.
2. From your description, this seems to be a copy error within VisualGDB (or .NET) itself. If CMake were to change the way it names files, this would simply be a band-aid over a more severe problem. This band-aid also wouldn’t work for the scenario where a build is located deep in a file system.

Best,

Noah

Attachments:

You must be logged in to view attached files.

[Noah]

The file does exist in

<PathToBuildOutput>\VisualGDB\Debug\.cmake\api\v1\reply

[Noah]

I also found that the file that it is looking for in the CodeModelCache,

directory-modules.hal_nxp.mcux.mcux-sdk-ng.devices.RT.RT1064.MIMXRT1064.devices.RT.RT1064.MIMXRT1064.drivers.devices.RT.RT1050.MIMXRT1052.drivers.flexram-DEBUG-532024778a5771ea2c83.json

does not seem to exist.

[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 1 year, 6 months 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

[Author]

Posts