Forum Replies Created
-
AuthorPosts
-
August 21, 2014 at 02:07 in reply to: Evaluating VisualGDB: some issues, thoughts and questions #3114
support
KeymasterHi,
Sorry for the delayed reply. We are currently investigating a potential regression with our updated ARM toolchain. We will address your issues within the next week. Sorry again for the delay.
support
KeymasterHi,
The previous version did not include the initialise_monitor_handles() method at all. In the current version it is used by the weak implementations of syscalls that can be overridden. Are you calling it initialise_monitor_handles() explicitly, or is it called by some syscall you are invoking?
support
KeymasterHi,
Based on our statistics the Kinetis devices are among the least commonly used. Hence we will be prioritizing support for other device families before. If you want to get it to work earlier, we can provide instructions on specifying the necessary flags manually. Just let us know.
support
KeymasterHi,
Yes, you can override the SSH port by specifying host:port in the “host name” field.
During “configuring” stage VisualGDB adds your public key to ~/.ssh/authorized_keys. If it hangs in this stage, please check whether the file is writable.
You can also disable the “setup public key authentication” and use the password instead.support
KeymasterHi,
If you want to attach to an app, please use the ‘Debug Custom APK’ command and select ‘attach to an existing instance’ when prompted.
support
KeymasterHi,
Can you attach a screenshot showing the missing menu item?
support
KeymasterHi,
This looks like a GDB bug (https://code.google.com/p/android/issues/detail?id=67938). Can you try experimenting with other toolchain versions in the NDK and/or different Android platform versions?
support
KeymasterHi,
Are you trying to attach to a native tool or an Android App?
August 18, 2014 at 19:59 in reply to: NDK: Eclipse + VisualGDB co-debugging – GDB command timeout #3141support
KeymasterHi,
Please try setting the Android->Debug Options->Do not Query Source Files option. This will disable certain workarounds that depend on the file-list-exec-source-files command, but should overall improve the performance.
support
KeymasterHi,
We received a lot of feedback from different customers regarding poor performance when using Raspberry Pi with WiFi, so we would suspect it to be the main cause. Let us know if you experience any problems with the wired connection.
support
KeymasterHi,
Sorry, please check debug.mak, not flags.mak.
August 7, 2014 at 23:06 in reply to: Evaluating VisualGDB: some issues, thoughts and questions #3122support
KeymasterHi,
We have re-ran the scenarios you described and will be publishing a maintenance release with a few fixes in the next few days. Meanwhile, here are the answers to the things you mentioned:
• It is OK to have several toolchains with the same arm-eabi ID. Actually, OpenOCD and Segger J-Link should work for any arm* toolchain (see %LOCALAPPDATA%VisualGDBEmbeddedDebugPackagescom.sysprogs.arm.openocdedp.xml:
^arm-.* ).
• Looks like there I may have been ambiguous about the custom projects. If you want to create a custom Embedded project with all Embedded functionality present, you still need to use the Embedded wizard and the select ‘specify flags manually’ on the Device Selection page:
[attachment=0:v5yzx4c9]flags.png[/attachment:v5yzx4c9]
• The memory stats and other embedded features should also work if you use the Embedded wizard in the manual flags mode.
• By default VisualGDB shows sizes in kilobytes if they exceed 10K and in bytes otherwise. Would you still prefer an option to override this manually?
• If you are selecting a device via the Embedded Wizard, the MCU definition file path is relative to the BSP directory. If you are specifying flags manually, it is relative to the toolchain directory. Hence simply place the definition files under the toolchain directory.
• We have added a check for the previous toolchain ID to the upcoming maintenance release. When you import a toolchain, VisualGDB saves its ID and other data in the toolchain.xml file in the toolchain directory. When you import a toolchain containing toolchain.xml one directory above gdb.exe, VisualGDB will now ask if you want to reuse the stored toolchain summary (including ID). Hence after importing the toolchain on one machine, simply copy the toolchain.xml to any other machine where you want to use the toolchain.
• You can achieve error line merging by creating a batch file and a PERL file. The batch file should be invoked from the Makefile and should invoke the compiler and redirect its output to the filter:<
> %* 2>&1 | C:cygwinbinperl.exe filter.pl The filter should buffer the error information and merge it with line number information in a GCC-compatible format:
foreach (
)
{
if (/<>/)
{
$error_info = $1;
}
elsif (/<>/)
{
if ($error_info ne '')
{
print "error: $error_info, $1, $2, <>";
$error_info = '';
}
}
else
{
$error_info = '';
print;
}
}Let us know if you need more details.
• Your template-based solution looks very good and flexible. We will consider including something similar to one of the new releases.
• We won’t be removing the Makefile support. Currently MSBuild integration is implemented in the vs-android project that facilitates building native Android code with Visual Studio and many our customers prefer it to the Android Make files due to its relative simplicity. We may provide a similar back-end for Linux and Embedded targets, but we will surely not drop GNU Make support.
• We don’t currently offer floating licenses, but if you want to move VisualGDB from one machine to another, you can contact our support to get the first one deactivated. Also for personal licenses we allow the use on one extra machine (e.g. a laptop).
• Beaglebone toolchain is not shown for the embedded projects as it is a Linux-based toolchain that is used with a different project type. This is by design.
• The custom project we mentioned before is an Embedded project with manually specified flags and not the project created with the custom wizard. Sorry for the ambiguity.Regarding the IntelliSense directories issue, this may have happened if the toolchain test was aborted due to some reason. If you can provide us with exact repro steps, we should be able to fix it.
support
KeymasterHi,
The “init mode failed” message is shown by OpenOCD when it has opened a handle to the ST-Link device, but the device refused the initialization command. This can be an indication of an old firmware used on your ST-Link. Can you try updating the firmware using the ST firmware update tool? If this does not help, please share the current state of the problem:
Does the settings testing always fail or just sometimes?
Does debugging work (always/sometimes/never)?
What exact problems are you experiencing with FLASH loading?support
KeymasterHi,
Based on your listing, VisualGDB should not attempt to use armeabi-v7a. Are you using normal debugging, or the Debug Custom APK option? What is the output of the VisualGDB Launcher Output in the Output window? Can you reproduce the problem on a smaller project and send us the entire project so that we could reproduce it on our side?
support
KeymasterHi,
First of all, please check that the flags.mak has been saved and successfully deployed to the Linux machine. If it has been deployed, double-check the Makefile. The following lines are responsible for using INCLUDE_DIRS:
CFLAGS += $(addprefix -I,$(INCLUDE_DIRS)) CXXFLAGS += $(addprefix -I,$(INCLUDE_DIRS)) ... $(BINARYDIR)/%.o : %.cpp $(all_make_files) |$(BINARYDIR) $(CXX) $(CXXFLAGS) -c $< -o $@ -MD -MF $(@:.o=.dep)
If the Makefile looks correct, but INCLUDE_DIRS is still ignored, you can experiment with it by modifying CXXFLAGS/INCLUDE_DIRS directly from the Makefile. If overriding the value at some line has no effect, most likely it is overridden somewhere after that line.
-
AuthorPosts