[support]

Hi,

This error indicates linker error and the Output window should contain more details about it. Most likely your linker script is corrupt or the program is too big to fit in the memory. In the latter case please select the newlib-nano library via VisualGDB Project Properties and try enabling the -Og optimization in the Visual Studio project properties (this is the optimization level that should not interfere with mots of the debugging features).

[support]

Hi,

No problem. BTW, if you want to add more text to the previous post instead of creating another one, you can use the ‘edit’ link.

Regarding the extra windows, most likely there is still some small mismatch between the paths. Please right-click on the tab header and select “Copy full path” for both tabs and compare the paths side-by-side in an editor.

Regarding Clang IntelliSense errors, again it is most likely caused by some small typos in include paths. We would recommend using VisualGDB 5.2 that will show a special hint if an include file is missing and will help you locating it via the Browse button and will then adjust the IntelliSense settings. If this does not help, please let us know the details on the errors you are observing and we will help you diagnose them.

[support]

Hi,

This means that your Linux machine is not running the OpenSSH server. If you are using a Debian-based distro, you can install it via the following command:

sudo apt-get install openssh-server

[support]

Hi,

VisualGDB uses the AutoDownloadedFiles folder for sources on the remote machine that were are not covered by path mappings known to VisualGDB (e.g. if your code uses a library with debug sources in /usr/src/<something>). Based on your description, VisualGDB cannot automatically detect that Windows folder that corresponds to the remote Linux folder, so it tries to download the files. This could be fixed very easily by adding a manual mapping on the Path Mapping page of VisualGDB Project Properties.

[support]

Hi,

The behavior you are describing happens in the “Allow choosing build/clean/debug command hosts independently” checkbox on the Project Settings page is not set. Please double-check that you actually set it. If this does not help, please send us your .vgdbsettings file so that we could check what is going on.

[support]

Hi,

Thanks for the link. The module looks interesting, but it’s currently very new and it’s hard to say how much demand it will get. We will continue monitoring its popularity and if it starts getting traction, we will add a BSP for it.

[support]

Hi,

VisualGDB indeed does not have a dedicated template for static Embedded libraries and will generate the usual LEDBlink code.

It will still be a library project, so if you simple replace the generated code with your library functions and reference the library from your main project, it should work.

[support]

Hi,

Looks like you are setting a breakpoint in C:/Users/billy_000/Documents/Micromouse/2017/MicromouseTest/MicromouseOrientationTest/Src/main.c, but the actual path to the file as reported by gdb is C:/Users/billy_000/Documents/Micromouse/2017/MicromouseTest/MicromouseTest/Src/main.c.

Please double-check that you are using the correct file. You can also use the ‘breakpoint diagnostics’ button in the GDB Session window to automatically setup a path mapping so that VisualGDB can substitute the paths for you.

[support]

Hi,

Thanks very much for reporting this. It looks like the new gdb reports the ‘failed to resume session’ events slightly differently and this totally confuses VisualGDB.

We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1324.msi

It will also be included in the next maintenance release of v5.2.

[support]

Hi,

Sorry for the confusion. We will try to explain it from scratch.

Visual Studio uses a concept of configurations (e.g. Debug/Release) to build different variations of your program. You can switch those configurations via the Visual Studio toolbar (the default configuration is “Debug”). VisualGDB follows this concept and also allows having multiple configurations per project. If you open VisualGDB Project Properties and click “Configuration: Add” -> “Create a copy of current configuration”, VisualGDB will copy the build and debug settings from the current configuration (e.g. Debug) to another one (e.g. Debug2). You can then switch between those 2 configurations to quickly switch between different sets of settings.

After you create the “Debug2” configuration please go to the Project Settings page and select your target machine in the “Computer used for building and debugging” field. Then uncheck the “deploy executable on a different machine” checkbox. This will make Debug2 a “direct build” configuration that will allow running gdb directly on the Linux machine without the use of gdbserver. The Debug Settings page will change (e.g. the “Deploy the main executable to” will disappear).

As you are still building your project on the Windows machine, you would need to switch to the regular “Debug” configuration to build it, then try debugging it so that it is deployed and then switch to “Debug2” to debug it in the direct mode desribed above.

You can also avoid the need to create a separate configuration by upgrading to the Custom edition. Then you will be able to tweak the normal “Debug” configuration to run gdb on the target machine. This process is described in detail in this thread: https://sysprogs.com/w/forums/topic/debugging-child-process/

Hopefully this clarifies the necessary steps. If you need further details, please let us know.

[support]

Hi,

No problem. If you encounter further issues, feel free to create another topic.

[support]

Hi,

Please look in the GDB Session window in Visual Studio and switch it to “All GDB Interaction”. This should display the internal commands that VisualGDB sends to gdb. Then clear the window contents, try setting a breakpoint and check the output. If it does not explain what goes wrong, please post the output here and we will help you understand what is wrong.

[support]

Hi,

Yes, as those custom steps are defined differently in different projects, VisualGDB cannot automatically import them. Hence the easiest way to add equivalents to them would be to add add either custom pre-build actions, or custom MSBuild targets.

[support]

Hi,

Sorry about that. Those crashes are most likely caused by bugs in the Clang compiler that VisualGDB uses in its IntelliSense engine. Unfortunately Clang sometimes crashes when it encounters incomplete code. Those crashes are usually caused by something very specific that is hard to find proactively (one of the last examples was a crash when trying to compute a sizeof() of a structure inherited from another structure that could not be fully parsed due to a syntax error in the middle of its declaration).

Most of those issues are very trivial to pinpoint and fix if you could send us the dump file. We usually fix them in less than 24 hours from the report and send a hotfix immediately. Please send us the dump file that VisualGDB produces and we should be able to fix this quickly.

[support]

Yes, you can do that if you are using the Custom edition or higher. Please follow the steps below:

1. Check the ‘Allow choosing build/clean/debug command hosts independently’ checkbox on the Project Settings page of VisualGDB Project Properties
2. On the Debug Settings page specify the following settings:
   1. Start gdb in the following mode: Custom mode
   2. GDB launch command: gdb –interpreter mi –args <executable path to debug>
   3. Use a gdbserver: no
   4. Target selection command: (empty)
   5. Debugging start mode: use “run” command

 

[Author]

Posts