Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
Note that we have added support for SSH key passhprases to SmarTTY 1.1 (http://smartty.sysprogs.com/download/)
support
KeymasterHi,
Fixed in SmarTTY 1.1 (http://smartty.sysprogs.com/download/)
support
KeymasterWe 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: 1With these settings VisualGDB will look for the ‘Listening on port …’ message, parse the port number in it and connect GDB to it.
December 16, 2013 at 06:14 in reply to: Running GDB on the deployment machine (lose the gdbserver) #2849support
KeymasterHi,
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=2839support
KeymasterHi,
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
KeymasterHi,
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
KeymasterIn 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
KeymasterHi,
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
KeymasterHi,
Unfortunately it’s not currently supported, however we will add this feature in the upcoming maintenance release (4.1r8). Thanks for your feedback.
December 5, 2013 at 07:53 in reply to: Bug in VisualGDB Project Properties/qmake project settings? #2838support
KeymasterHi,
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?
support
KeymasterHi,
We tried your project, for us the breakpoints were set both in the project and library files. Have you tried rebuilding the project?
If you still experience issues with breakpoints, try the Android breakpoint issues tutorial for hints or submit us a full gdb log.
December 5, 2013 at 07:27 in reply to: Running project locally with cross-compiler vs linux network #2837support
KeymasterHi,
It looks like the project is successfully built but fails to be deployed to Raspberry Pi. Try deploying manually to see if it fixes the problem.
To do it, in Visual Studio go to Tools->SSH Host Manager and open a console using the Raspberry Pi connection. You can use the SCP menu to transfer the project’s executable from C:inetpubwwwrootFlashGrowDBFlashGrowDBDebug” to /tmp on Raspberry Pi.December 2, 2013 at 07:36 in reply to: Running project locally with cross-compiler vs linux network #2835support
KeymasterHi,
Thanks for finding that out. It looks like your GCC does not create a valid binary when being tested, but also does not return any error code and that confuses VisualGDB. Could you please press the “ignore” button in the error dialog and see whether a buildable project is created?
support
KeymasterHi,
This looks like a bug in our toolchain. Thanks for reporting it, we will fix it in the next release. In the meanwhile please use the following workaround:
1. Download mv.exe to SysGCCRaspberrybin
2. Modify SysGCCRaspberryarm-linux-gnueabihfsysrootusrshareqt4mkspecsarm-linux-gnueabihfqmake.conf so that QMAKE_MOVE is set to mv:QMAKE_MOVE = mv
3. Create a file called ln.bat in SysGCCRaspberry with the following contents:
copy /y %2 %3
December 1, 2013 at 04:50 in reply to: Running project locally with cross-compiler vs linux network #2833 -
AuthorPosts