Forum Replies Created
-
Posts
-
Hi,
Thank you for the additional information, we will use it to recreate, diagnose and fix the issue.
In the meantime you can use the following workaround to set breakpoints in your app:
1. Attach to the process as usual.
2. Press on ”Break all”.
3. Look for the “Show a list of all source files” button in the GDB Session window, you may have to enlarge the window to see it. Click on the button.
4. This tool lists all source files GDB knows, you can also open those files in VS with the tool and set breakpoints as usual in them. VisualGDB will fetch the files from the remote machine automatically.Lastly you can also set breakpoints manually in the GDB Session window.
Hi,
Yes, for you can find the arm-eabi toolchain here: http://gnutoolchains.com/arm-eabi/
Hi,
We need more information to diagnose the issue. Could you please post a screenshot showing the code, the breakpoint window and gdb log?
Hi,
Reinstall the latest Raspberry Pi toolchain from http://gnutoolchains.com/raspberry/ . It was updated a couple of days ago to also include the test tool.
Hi,
Most likely the key file format is not supported by libssh2 that SmarTTY uses. Please try other authentication methods.
Hi,
You can change the linker script to control the way the code is placed into memory. Look into the build output of your project. The pre-last line building the elf file includes the linker script that specifies the starting address. Edit that lds file to start from a different address.
Please note that if you simply relocate the start of the flash memory to the new address, the ISR vector will also be placed there that is probably not a valid configuration.Hi,
gcc does not support recursive include directories. The point about include paths is to be able to pick and choose which directories to include. Your current IDE is probably adding all the subfolders to includes automatically.
There is nothing wrong with separating files into folders, it only means that you either need to refer to them based on their relative paths or add the folder paths to include directories. The usual point about making subfolders for code is to be able to include only partial subsets for compilation to reduce compile time for some targets. If many subfolders of headers need to be included, then there is usually a master header file to include instead which in turn refers to all the headers in their subdirectories. For Visual Studio c/c++ projects creating actual subfolders to sort the code for more convenient development is not necessary as the folders in Solution Explorer are virtual anyway and you can create as many virtual folders as you want while still having all the code in one physical folder. You can switch viewing modes in Solution Explorer by enabling and disabling the “Show All Files” button at the top.
Hi,
If the errors you are getting are compilation errors, then you need to add include directories. If you are using VisualGDB makefiles, then simply go to VisualGDB Project Properties and add the include directories(the directories your files are directly in) to the include directories list in the makefile settings. If you are using your own makefiles, then you need to add the equivalent -I statements to your build recipes.
If the errors are Visual Studio IntelliSense errors, then again go to VisualGDB Project Properties and add the directories to the IntelliSense directories list. If you are using VisualGDB makefiles, then all include directories are added to IntelliSense directories automatically.
Hi,
VisualGDB first tries to use the full path when setting breakpoints. If that fails, then the path from ‘info sources’ is used.
To analyze the breakpoint issue further please give us a full GDB log. So please enable diagnostic logging in the GDB settings page of VisualGDB Project Properties. Then start debugging, replicate your scenario i.e. try to set a breakpoint, stop debugging, send us the gdb log file from your project directory.
Hi,
Those flags should normally avoid using any not explicitly specified libraries. It is hard to say more without even seeing a single error message you are having.
Of course another thing to remember with cross-compilation is that the shared libraries used for building and running are not necessarily the same.Hi,
The precompiled header setting only applies to Windows projects in Visual Studio.
However, you can replicate the same behavior also with gcc/make. Look in gcc documentation for hints on how to modify the makefile:
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.htmlHi,
First of all make sure that all of the code is built in debug mode with symbols. If your project depends on libraries that you want to debug as well, these libraries must also be built with symbols.
Secondly, have you tried the breakpoints diagnostic tool to fix the path mapping? It is described in the breakpoint problem diagnosing tutorial (relevant from point 19 onwards):
http://visualgdb.com/tutorials/linux/bp-diag/Hi,
This error means to look inside the Output tool window for more clues as the problem cannot be mapped to source files.
Add include paths in VisualGDB Project Properties in Makefile settings. Depending on NDK version it may prefer relative paths.
Do not include STL headers manually to includes, it can give compilation problems, setting the STL in Application.mk is enough. The Android build system will then fetch the headers doing building automatically. Do add the appropriate STL header include to IntelliSense directories, along with …android-ndk/sources/cxx-stl/gnu-libstdc++/4.7/libs/armeabi/include/bits as it contains the stl definitions, including this will solve most of the IntelliSense errors.
Hi,
Thanks for the great idea. Currently heap inspection is not part of VisualGDB features. Overall adding functionalities from DDMS to Visual Studio through VisualGDB is in our plans.
As VisualGDB version 4.1. is already approaching release, we have added heap inspection to the planned feature list of VisualGDB version 4.2.
