Noah

Forum Replies Created

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • 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.

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

    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, 4 months ago by Noah.
    • This reply was modified 2 years, 4 months ago by Noah.
    • This reply was modified 2 years, 4 months ago by Noah.
    Attachments:
    You must be logged in to view attached files.
    in reply to: Debugging Failed with Remote Linux #31458
    Noah
    Participant

    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, 4 months ago by Noah.
    in reply to: Debugging Failed with Remote Linux #31454
    Noah
    Participant

    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, 4 months ago by Noah.
    Attachments:
    You must be logged in to view attached files.
    in reply to: Debugging Failed with Remote Linux #31451
    Noah
    Participant

    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

    Attachments:
    You must be logged in to view attached files.
    Noah
    Participant

    Ok thank you.

    For the record, the latest ARM toolchain from Sysprogs fails in the exact same way.

    Noah
    Participant

    On second inspection, the rules.ninja file exists. Seems to be a lexing error with paths (think “C:”).

    Trying to compile other projects with 10.3.1 also fails in the same way, and 10.2.1 also makes it work again.

Viewing 9 posts - 1 through 9 (of 9 total)