[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

 

[support]

Hi,

Sorry, we do not officially support building the embedded projects remotely. You should be able to import it in a custom mode and setup everything manually, but if you are not familiar with Linux internals, we strongly recommend copying the sources to the Windows side and importing them by following our regular import tutorial: http://visualgdb.com/tutorials/arm/import/

[support]

Hi,

Please double-check that you have the “Enable GDB stub” checkbox enabled in VisualGDB Project Properties and that your code calls gdbstub_init().

If this does not help, please try connecting to your COM port with SmarTTY or any other terminal program, enter the baud rate from the “GDB Stub Baud Rate” field in VisualGDB (normally 74880) and reset your board. Once GDB stub takes control, you should see the following output:

$T05#b9

If instead you see an error message, your board might be defective. If you don’t see anything or see total gibberish instead, please try experimenting with the baud rate (e.g. try 115200). Once you find out a baud rate that works, ensure you enter it in the GDB Stub Baud Rate field.

[support]

Hi,

No problem. We would advise to backup your .vgdbsettings file with the settings that work so that if it stops working again you could compare the settings and see what breaks it.

[Author]

Posts