[support]

Hi,

Please try the following build: http://visualgdb.com/tmp/VisualGDB-5.0.3.310.msi

We have made the following changes:

• When using Gradle build subsystem, VisualGDB now uses the $(SourceDir)\$(GradleAppSubdirectory)\build\intermediates\manifests\full\$(GradleFlavor)\$(GradleBuildName)\AndroidManifest.xml file to determine the package/activity names and other settings. I.e. all changes caused by the Gradle flavor will be now read correctly. The path (that appears to be hardcoded in Gradle) can be currently modified by editing the .vgdbsettings file manually.
• VisualGDB now uses the zipalign$(GradleFlavor)$(GradleBuildName) as the gradle task name. The GradleFlavor can be defined via VisualGDB Project Properties as before.
• VisualGDB now does not edit the AndroidManifest.xml file if it has successfully found a generated manifest file from the intermediates folder.
• You can specify additional arguments to Gradle by adding a VisualGDBProjectSettings2/Build/AdditionalGradleArguments element to the .vgdbsettings file (no GUI setting for it yet).
• In case of multiple apk files VisualGDB checks whether the $(app subdirectory)-$(gradle flavor)-Debug.apk file is present. If it is found, it is automatically selected without showing any extra windows.
• If VisualGDB has to rebuild the .jar file, it now displays the file that caused the rebuild.

The build output is actually still available if you select ‘build’ in the “show output from” field. Opening VisualGDB Project Properties switches the output view to VisualGDB internal output.

[support]

Looks like your kernel is configured without kgdb support. Please enable it via kernel configuration interface and then build kgdboe again with the new headers.

[support]

The SIGSEGV is most likely caused by the workaround VisualGDB utilizes to fix issues with library symbol loading. Please try switching the workaround method or disabling it completely.

VisualGDB rebuilds the .jar file when any of the .so files that go into it has a more recent timestamp than the .jar file itself. Please double-check why your .so files get rebuilt.

Regarding the gradle flavor issues, we will do a full investigation/analysis of that after we release the new clang-based IntelliSense engine. Before that we should be able to provide hotfixes that should make debugging possible with reasonable manual adjustments. Could you make and send us a small small repro case demostrating the broken build/launch for a custom flavor? We should be able to release a hotfix based on it very quickly.

[support]

Hi,

As your scenario (debugging a completely custom kernel) is very rare, we will most likely not create a separate product supporting it. However what we can do is extend the VisualGDB plugin interface so that you could add your custom tool windows and use the convenient VisualGDB SDK interfaces to query various data from the GDB session. Let us know if that works for you.

[support]

Looks like the LinuxProject1.cpp file did not get transferred to the remote machine and hence GNU Make cannot find it. Please double-check your file transfer settings and ensure this file exists on the Windows side.

[support]

Hi,

The seat ID is shown directly in the form that displays the link to the activation page.

[support]

Hi,

Please try the newest VisualGDB 5.0 Preview 3 build. It supports customizing the Gradle flavor via VisualGDB Project Properties dialog.

[support]

You cannot reliably combine code from MS C++ compiler and GCC in one module as those compilers have too many differences. However you can create shared library (.DLL) using VisualGDB and load it from your MSVC-compiled app (or vice versa). As long as those are 2 different modules, it should work.

[support]

Hi,

Simply add “-j <number of cores>” to the Make command line arguments in VisualGDB Project Properties to enable parallel building.

[support]

The easiest solution would be to pass the directory of the main makefile and then add further files to your project via <right click in Solution Explorer>->add->Add folder recursively.

[support]

Yes, you can follow this tutorial: http://visualgdb.com/tutorials/raspberry/qt-cross/

[support]

Hi,

Sorry for the delayed reply. Please find the answers to your questions below:

1. If you are using VisualGDB 4.3r4, the TOOLCHAIN_ROOT should be set on-the-fly based on the current project toolchain. Please double-check that it’s defined with the ?= syntax in mcu.mak and that the environment variable is passed correctly (add ‘set’ to build commands in Makefile to get a dump of the environment).
2. Visual Studio project variable system is different from VisualGDB variable system, so the IntelliSense includes cannot reference VisualGDB variables. Simply specify the relative paths to your include directories (e.g. ..\include) and they will be handled correctly.
3. This is a known issue that has been fixed in the upcoming 5.0 release.
4. This is caused by a bug in the texane-STLink tool that VisualGDB uses. Simply unplug your ST-Link and plug it back to get it fixed or switch to OpenOCD that does not have this problem.
5. This is a limitation of VS. VisualGDB projects are Makefile projects, so Visual Studio has no way of determining whether any of the files have changed. We do have long-term plans of transparently supporting MSBuild, that will eliminate this problem, but currently the only workaround is to answer ‘no’ if you are 100% sure that the project has not been modified. VisualGDB will then debug the previously built binary.
6. There is no special procedure. The installer simply unpacks an archive and registers the toolchain with VisualGDB. Simply delete the toolchain folder and VisualGDB will recognize that it’s gone.
7. We do have plans to support HAL for other device families and also allow selecting between HAL and classic frameworks, however this is planned after the release of the new IntelliSense engine.
8. You can easily achieve that by adding ‘-jXXX’ to VisualGDB Project Properties -> Build Settings -> Additional Arguments.
9. This might be quite tricky to support properly (GDB/VS won’t support it natively, so we would have to add some special GUI for that) and it will only work with GDB stubs that provide a command interface that is separate from GDB. You should be able to achieve a similar result if you use OpenOCD, telnet to port 4444 while it is running, and run commands like “mdw <addr> <count>” to query memory contents directly from it (bypassing VS and GDB). Let us know if that works for you.
10. We did experiment with ST-Link/V2 and SWW (built an open-source trace tool from https://github.com/obe1line/stlink-trace) and found out that at seemingly random points in time the ST-Link device enters some internal state where it simply starts producing garbage instead of the trace output. Furthermore, different firmware versions showed different behavior, so we gave up. If you are willing to experiment with it and could get the tool to work reliably, we could help you port its functionality to OpenOCD so that VisualGDB would support it directly. You can find the source with our modifications to get it working on STM32F4Discovery here: http://visualgdb.com/tmp/trace.zip (Disclaimer: we are not related to the author of the tool and find parts of its code as puzzling as you will).

11. (Regarding the <MCUDefinitionFile>). Thanks for letting us know, we will include a fix in the upcoming 5.0 release.

[support]

Could you share the full GDB log as described here?

[support]

Hi,

You can convert your project to a stand-alone project to copy all shared files to the project directory. Alternatively you can remove the startup file from the device-specific files and add a local copy instead. VisualGDB project system is quite resilient and will not be broken by changes like that. The original startup file will be re-inserted into the project only if you change the MCU type (or MCU properties) via VisualGDB Project Properties forcing it to regenerate the settings files.

The gcc_Debug.h file contains macros that are defined by GCC itself (e.g. GCC version) and the macros specified via command line. The STM32F10X_MD_FL macro defines the current MCU family and comes from the stm32.mak file the stm32.mak file is generated from data in %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\BSP.XML and contains the basic settings expected by the STM32 code. When you change the current MCU type, VisualGDB will recompute the flags necessary to build the code for it and will regenerate stm32.mak. If you want to add your own preprocessor macros (e.g. controlling the clock settings), use the VisualGDB Project Properties dialog (Makefile Settings page) that will save them to the debug.mak file instead.

The source control integration should work transparently as long as your check in the .vgdbsettings files from your project directory. You can reference your external libraries using relative paths on the Makefile Settings page and check in them as well.

Setting up a different compiler like IAR would be a bit more complicated. VisualGDB uses the GNU Make tool to build the projects. The GNU Make reads the rules from Makefile and files included from it and uses them to determine which files are outdated and what commands are used to rebuild them. In order to use IAR you will need to replace the Make rules that invoke GCC with Make rules that invoke IAR. This will involve changing the GCC-specific command-line arguments to IAR-specific command-line arguments and updating regular expressions that VisualGDB uses to parse error messages.

The interrupt handlers are supported via the GCC “weak reference” mechanism. The shared startup_stm32xxx.c file contains definitions like this:

void NMI_Handler() __attribute__ ((weak, alias ("Default_Handler")));

Then it builds the interrupt vector table that is placed to the specified location in FLASH:

void * g_pfnVectors[0x6b] __attribute__ ((section (".isr_vector"))) = 
{
 &_estack,
 &Reset_Handler,
 &NMI_Handler,

If your project defines another implementation of NMI_Handler, the linker will replace the default “weak alias” with it and the interrupt vector table will point to it instead. Hence there is no need to modify the shared startup_stm32fxxx.c  file – simply ensure that each project provides its own replacement of all necessary handlers.

If you want to have several different projects using different modifications of the startup file, simply modify it this way:

#ifdef USING_BOARD_1
//Code specific to board 1
#elif defined(USING_BOARD_2)
//Code specific to board 2
#else
#error Board not defined
#endif

Then define USING_BOARD_1 or USING_BOARD_2 on the Makefile Settings page of your project settings. As different projects will have different macros defined, the same shared startup file will work differently for each of the projects.

[support]

Hi,

We’ve made the modification you suggested and it will be included in the next preview build of VisualGDB with our new IntelliSense engine. Would you like to get a test build to try it out before we release that?

Regarding the threads window, there is no public API to add further columns, or even get the currently selected threads. However, as it is WPF-based, you can use .Net reflection to hack things dynamically (e.g. add columns on-the-fly) without breaking VS functionality. This will however most likely break in subsequent VS versions and would require modifications to accommodate the changes in the internal structure of the threads window.

[Author]

Posts