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

[support]

Hi,

If your versions of nasm and gdb are compatible, VisualGDB should not have any problem with it as long as you specify the correct flags in the Makefile.
Please see this page for hints on setting nasm to work with gdb: http://www.csee.umbc.edu/portal/help/nasm/nasm.shtml

[support]

Hi,

Sorry for the confusion. VisualGDB supports 2 way of doing this:
1. You can use the Quick Debug feature (from the Debug menu) to start GDB with the arguments/settings you manually specify and let VisualGDB connect it to Visual Studio.
2. You can create a custom project using the custom project wizard and manually specify build command, clean command and GDB launch command.

[support]

Unfortunately this scenario is not supported „out of the box“, as there is no standard way of sending files and forwarding GDBServer output via the COM port at the same time.
However if you believe it’s a major timesaver, you could make a tool that would do that and configure VisualGDB to debug using it. Let us know if you need more details about this.

[support]

Hi,

Note that we have added support for SSH key passhprases to SmarTTY 1.1 (http://smartty.sysprogs.com/download/)

[support]

Hi,

Fixed in SmarTTY 1.1 (http://smartty.sysprogs.com/download/)

[support]

We have added support for dynamic port detection to VisualGDB 4.1r8. You can download it from http://visualgdb.com/download/VisualGDB-4.1r8-trial.msi
Do use this feature please select “Debug with a custom GDB stub” on the Debug Settings page, then setup the stub as “gdbserver” with arguments “:0 $(TargetPath)”.
Then click on “Setup advanced GDBServer settings” and specify the following settings:

Wait to ensure the server starts: 5000 msec
End waiting when the server outputs text: [yes]
Regex: Listening on port ([0-9]+)
Override GDBServer port: [yes]
Regex group: 1

With these settings VisualGDB will look for the ‘Listening on port …’ message, parse the port number in it and connect GDB to it.

[support]

Hi,

Using remote gdb for a binary built with a cross-compiled would not be straight-forward, so we would recommend using dynamic gdbserver port instead.
Please see the reply in viewtopic.php?f=5&t=2839

[support]

Hi,

We looked more into this. Actually, you can simply use the COMPUTERNAME variable that is available on Windows XP and newer versions. Use $(COMPUTERNAME) in your commands in VisualGDB settings.
Note that you can also use any other environment variables of the current Windows user (if a build variable with the same name exists, it will override the environment variable).

[support]

Hi,

You could exclude some source files by replacing this line in Makefile:

all_source_files := $(SOURCEFILES)

with this:

all_source_files := $(filter-out $(EXCLUDED_FILES),$(SOURCEFILES))

Then you can define EXCLUDED_FILES in your per-configuration .mak files to have those files excluded from build.

Regarding configuration reuse, unfortunately there is no direct way. VisualGDB Project Properties editor is way more sophisticated than Visual Studio configuration editor and it heavily relies on the ‘current configuration’ concept (e.g. it substitutes configuration variables on-the-fly, allows browsing files on the currently selected remote machine, etc).
However, you can use the following techniques to reuse some of the settings:
1. VisualGDB Make Settings editor edits the .mak file for the current configuration, it does not regenerate it. You can move the common settings to a separate .mak file (e.g. CFLAGS += -ggdb) and include it from the configuration files.
2. All VisualGDB settings are stored in -.vgdbsettings files. Those files are XML files generated by .Net serializer from public objects inside VisualGDB.EXE assembly. If you are dealing with plenty of configurations you may want to generate those on-the-fly. Using the .Net serializer it’s a very straight-forward process.
3. VisualGDB supports an project extension mechanism that allows creating .Net extensions to automate things not directly supported by VisualGDB. We could extend it with a method to patch the project settings on-the-fly before building or debugging so that you could have only one .vgdbsettings file and a basic extension DLL that sets the architecture-specific parameters based on the platform.

[Author]

Posts