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

[support]

In order for Visual Studio to edit your project files, the files need to be accessible from the Windows machine. You can either create a local copy and re-upload modified files each time, or share your project directory on Linux with Samba and mount it on Windows so that Visual Studio accesses them directly.

Both options are available via the VisualGDB Project Wizard:
1. On the first page select “Import a project built with command-line tools”
2. On the third page select “The sources are already on “
3. On the fourth page select how do you want to access the sources.

[support]

Hi,

Looks like the project your are trying to build depends on some Linux-style tools.
You can actually install Cygwin, add Cygwin directories to PATH and try building it again using make.exe from cygwin. This should normally work, as cygwin provides most of Linux tools on Windows (ensure that you install the necessary packages).

[support]

Hi,

Unfortunately it’s not currently supported, however we will add this feature in the upcoming maintenance release (4.1r8). Thanks for your feedback.

[support]

Hi,

We are aware of the first issue and will be releasing a fix in the next r release. It is safe to ignore the toolchain test fail and save the settings anyway as the issue is only with toolchain testing.

For the second issue, in the Qt pro file both library names and directories are stored in the same location. VisualGDB displays them in different fields to allow custom editors such as folder browsing. In the debug.pro file, what is the value of the LIBS variable?

[Author]

Posts