Noah

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 21 total)
  • Author
    Posts
  • in reply to: System.IO.PathTooLongException #36919
    Noah
    Participant

    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.
    in reply to: System.IO.PathTooLongException #36913
    Noah
    Participant

    The file does exist in

    <PathToBuildOutput>\VisualGDB\Debug\.cmake\api\v1\reply
    in reply to: System.IO.PathTooLongException #36912
    Noah
    Participant

    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.

    in reply to: Memory Exhausted Error #35554
    Noah
    Participant

    Perfect, thank you!

    in reply to: Memory Exhausted Error #35511
    Noah
    Participant

    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.
    in reply to: Memory Exhausted Error #35509
    Noah
    Participant

    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.”

    in reply to: Memory Exhausted Error #35506
    Noah
    Participant

    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.

    in reply to: Memory Exhausted Error #35502
    Noah
    Participant

    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.
    in reply to: Memory Exhausted Error #35500
    Noah
    Participant

    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

    in reply to: Memory Exhausted Error #35497
    Noah
    Participant

    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.
    in reply to: Memory Exhausted Error #35493
    Noah
    Participant

    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.
    in reply to: Memory Exhausted Error #35483
    Noah
    Participant

    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

    in reply to: Change Debugged Application #32926
    Noah
    Participant

    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.
    in reply to: Debugging Failed with Remote Linux #31470
    Noah
    Participant

    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

    in reply to: Debugging Failed with Remote Linux #31469
    Noah
    Participant

    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.

Viewing 15 posts - 1 through 15 (of 21 total)