Forum Replies Created
-
Posts
-
Hi,
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?
Hi,
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.
Hi,
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.
Hi,
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.
Hi,
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?Hi,
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?
Hi,
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.
Hi,
The -g flag won’t slow down your program (as long as you keep the -O2 option), but will increase the binary size by putting debug symbols in it (that can be removed later by running the strip tool). However in the debug configuration it’s recommended to turn off the optimization (replace -O2 with -O0) as it will make debugging much easier (e.g. stepping through code can look semi-random with -O2 due to code reuse). We recommend using “-O2 -ggdb” options for the release build and the “-O0 -ggdb” options for the debug build.
Hi,
Please remove the
libsarmeabi-v7a directory if you are not building the armeabi-v7a target. Then VisualGDB will automatically switch to using armeabi. Hi,
It’s hard to tell from just this statement, but looking at the preprocessor output (expansion of #define statements) should most likely provide a clear answer. Run “gcc
-E file.c -o file.e” and then examine file.e (search for main() there as the file will be huge due to expanded #include directives). If the output is not helpful, please post the line that causes the error here. Hi,
From a quick look this looks more like a GDB issue. The ‘break all’ simply sends a Ctrl-C event to GDB. You can try experimenting with the set follow-fork-mode command or go to the Custom Debug steps page of VisualGDB Project Properties and override the ‘Break All’ action with a ‘killall -s INT ‘ command to send a SIGINT to all instances you’re debugging.
