[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.

[support]

Hi,

First of all, thanks for the feedback. The issues you mentioned indeed take place when debugging Android apps, however they are not specific to VisualGDB. In fact, those are the bugs of the Android NDK and SDK and unlike other tools like NVidia’s pack, VisualGDB provides diagnostics and workarounds for them (e.g. breakpoint diagnostics, automatic detection of cases like ‘too many apps’, etc.) and we do offer help for them with our support. It is likely that a clean image of Ouya will work more reliably with NVidia’s tool than an arbitrary Android device with many apps with VisualGDB, but the reason is not that VisualGDB is less reliable, but rather that Android tools themselves exhibit problems when it comes to bigger setups. Another limitation of Nvidia’s tool is that is only works for NVidia chipsets, while VisualGDB supports all of them. Finally, VisualGDB provides numerous ways to customize building and debugging and tweak the underlying tools in many different ways.

Regarding the license switch, we could offer you an upgrade to Ultimate edition that combines the features of Linux, Android and Custom editions. Please contact sales@sysprogs.com to get a quote.

[support]

Looks like port 2000 is used by some other program (or another instance of gdbserver). Please run ‘killall gdbserver’ and if it does not help, change the port number.
Please also change ‘debugging start mode’ to ‘continue command’ and double-check your target remote argument. GDB is ran on Windows and it cannot refer to a pipe name on a Linux machine, it has to be :.

[support]

Hi,

Sorry for the long delay; please use the email or the contact form on the website for urgent inquiries.
Regarding cross-compilation, it really depends on what level of redirection does your relay service provide. When debugging Beaglebone on your local network using GDB, the gdb.exe is started on Windows and it connects to gdbserver on your Beaglebone board using the gdbserver protocol (usually port 2000). Please configure your relay service to redirect port 2000, then go to VisualGDB Project Properties, select “Custom mode” in the “Start GDB in the following mode” and specify “target remote :” as the target selection command (connecting to host and port specified there should connect GDB to redirected port 2000 on Beaglebone). Please also enable the “use a gdbserver” checkbox and specify the gdbserver command line there.

Please let us know if you encounter any problems.

[Author]

Posts