[support]

Hi,

Yes, this would require quite a lot of effort making a new generator for CMake. Currently we have no plans of doing that, however if anyone from the community volunteers to provide such support, we will provide them as much help as we can.

Note that the .vgdbsettings file also contains debugging settings, so it’s hard to generate it purely based on the cmake file.

[support]

Hi,

You need to install the SSH server on Ubuntu:

sudo apt-get install openssh-server
sudo service ssh start

[support]

Hi,

What level of CMake support would you like? Just wizard/makefile updating or something more specific?

[support]

Hi,

The problem is that printf() inside itself uses ‘double’. Although you pass a float there, it reads ‘%f’ in your string and somehow converts it to double. You cannot change this behavior by modifying your program as it is located inside the printf() that is a part of the standard library. You could either modify the standard library used by GCC (which is somewhat cumbersome), or simply use another open-source implementation of printf() (there should be plenty of those available online).

[support]

Hi,

This problem means that the standard C library has been compiled in a way that treats the ‘%f’ format in a way that uses the double type. We would recommend simply using an alternative implementation of sprintf() from some open-source library and tweaking it so that it only uses the float type.

[support]

Hi,

Unfortunately this is a limitation of Windows. Although we could workaround it by using UNC names internally, Visual Studio will still not be able to open those files. Please note that this should not affect your build: the kernel is built on the Linux system and those files will simply not be overwritten. Please let us know if you encounter some of files with reserved names that are essential for debugging. We will then add support for renaming them during import (e.g. con_.h) and seamlessly mapping the names during file transfer and debugging. This is bit cumbersome, however it looks like the only way to work around the Windows/VS limitation.

[support]

Hi,

Thanks for reporting it, we will include a fix in the next maintenance release.
Regarding VisualDDK, we have no current plans of releasing further versions, as Microsoft includes Visual Studio support in the latest WDK and many people consider VisualDDK obsolete. We may eventually invest in that direction, but certainly not within the next year, as we are now focusing on increasing usability of VisualGDB.

When we decided to stop active development of VIsualDDK, we made it open-source. If you are interested in making a VS2013-compatible version, you can simply use the source code and replace registry keys/assembly references. If you have any questions about building it, feel free to ask on the corresponding forum.

[support]

The current design supports two levels of nesting:
1. You can define register sets that support registers. This is implemented and fully supported.
2. You can define bit ranges inside each register. Each bit range can be mapped to a combo box with predefined values or a check box. This is supported by the VisualGDB back-end but we don’t have GUI for it yet.

Here’s the definition of the hardware register-related types in VisualGDB:

    public class HardwareSubRegister
{
public string Name;
public int FirstBit;
public int SizeInBits;

/// 


/// Only valid when contains array of (1 << SizeinBits) strings.

/// If set, instead of showing one of the actual integral values, a corresponding string

/// should be displayed and a combobox should be used.

/// 


public string[] KnownValues;



[XmlIgnore]

public HardwareRegister ParentRegister;

}



public class HardwareRegister

{

public string Name;

public int SizeInBits;

public string Address;          //0x...

public string GDBExpression;    //Optional, can be derived from Address

public bool ReadOnly;

public HardwareSubRegister[] SubRegisters;

}



public class HardwareRegisterSet

{

public string UserFriendlyName; //If not set, not displayed either

public HardwareRegister[] Registers;

}

Do you think this format supports all the grouping you need? If no, please give us an example of grouping that is not supported. If yes, please give us a sample XML file with the grouping you want so that we could add this feature to our GUI.

[support]

The problem most likely happens because your toolchain maps the file paths in a way unknown to VisualGDB.
Please use the ‘breakpoint diagnostics’ feature (see this tutorial for more details, it is about Linux, but it should be similar to your case). If the diagnostics feature does not help, please run the info sources command and post its output here so that we could help you with setting up file mapping.

[support]

Hi,

Thank you for the feedback. Currently the automatic detection is not supported, however we agree that it would be a useful feature. We have added it to the roadmap of the next version of VisualGDB.

[support]

Hi,

Thanks for letting us know this feature is important for you. We already support peripheral register listing for msp430, but we did not add it for ARM yet.
You can easily let VIsualGDB display the registers of your MCU by editing some of the configuration files manually:
1. Ensure that your .vgdbsettings file has a reference to an embedded profile file (e.g. stm32.xml):

Debug







MinGWUnixSlash



$(ProjectDir)

stm32.xml



...

2. In the embedded profile file add an MCUDefinitionFile element pointing to an XML file on your disk:

com.visualgdb.arm-eabi

com.sysprogs.arm.stm32

STM32F407VG

...

e:stm32registers.xml

3. Create an MCU definition file listing the peripheral registers in the following format:

stm32-demo





GPIOC





MODER

32

0x40020800






IDR

32

0x40020810

Once you create those, start debugging and open the Hardware Registers window to see the contents of your registers.

[support]

VisualGDB already does the error message conversion from GCC format to Visual Studio format. It relies on regular expressions do parse the messages. You can override those regular expressions by creating a file called BuildMessageTemplates.xml in the VisualGDB directory with the following content:

^([^:]+|[a-zA-Z]:[^:]+|):([0-9]+): (error|fatal error|warning|note|Error):(.*)$

^([^:]+|[a-zA-Z]:[^:]+):([0-9]+): (undefined reference to .*)$

^([^:]+|[a-zA-Z]:[^:]+):([0-9]+): (multiple definition of .*)$

^([^:]+|[a-zA-Z]:[^:]+|[a-zA-Z]:/[^:]+):([0-9]+):([0-9]+): (error|fatal error|warning|note):(.*)$

make[([0-9]+)]: (Entering|Leaving) directory (.*)$

([^:]+):([0-9]+): *** (.*)$

Simply update the regular expressions there to match the IAR output and VIsualGDB will understand them.

[support]

Hi,

Last time we checked, IAR for MSP430 did not support producing ELF files with GDB-compatible symbols. If the ARM version supports it, you should be able to switch from GCC to IAR compiler by simply modfying the makefile generated by VisualGDB. As long as the ELF files are GDB-readable, VisualGDB will automatically support them.

Please let us know if you need more information on doing that.

[support]

If you want to set the environment variables to some static values, simply select “Use a custom GDB executable” on the Debug Settings page in VisualGDB Project Properties and specify the environment variables there.
If you want to do some computations and set the variables based on those, create an executable shell script (e.g. run-gdb.sh) that will set the necessary variables and then invoke gdb with the command line arguments passed to the script, e.g.:

export A=B
gdb $@

Then specify the location of that script file in the “GDB Debugger Executable” field in custom GDB settings editor.

[support]

Hi,

Unless nasm uses some special path encoding style, breakpoints should work normally. If they don’t, please follow the breakpoint diagnostic tutorial to fix them.

[Author]

Posts