Forum Replies Created
-
Posts
-
Yes, simply use the File->Export VisualGDB Project Template command. We will publish a tutorial on that soon.
Wow, strange. It did not crash on our side. If anyone else can confirm the crash, please send us dump file and we’ll gladly fix it.
Hi,
OK, strange. According to your log file, the breakpoint gets set correctly. Please try modifying your code as follows:
- Add a function “void test() {asm(“nop”);}
- Change the stringFromJNI() function to return the address of the test() function instead of the counter: sprintf(sz, “test=0x%x”, &test);
- Set a breakpoint in ‘test’ by name (Ctrl-B).
Does the address of ‘test’ reported in the GDB log match the address returned by the stringFromJNI() function? Does the breakpoint still not hit?
Hi,
OK, what is value assigned to APP_ABI in your Application.mk? Does it include arm64-v8a? If not, please add it there:
APP_ABI := arm64-v8a
Hi,
Please find your answers below:
- We do allow using a personal license on one additional computer (e.g. a laptop).
- The license is perpetual, however the free updates and support will only work for 1 year.
- We don’t have any plans for making an Eclipse plugin, as many Eclipse users prefer free tools and may not justify the costs of a plugin like VisualGDB. You can, however, use the free Visual Studio Community edition with VisualGDB if you don’t have a regular Visual Studio license.
Hi,
It’s hard to say why these errors are happening if you are using C99. Could you please share the full build log from the Output window? Perhaps you have enabled strict type checking via CFLAGS?
Hi,
The Source Cache Manager is used to cache the remote source/header files (e.g. in /usr/src) that are not a part of the project but somehow participated in build, hence they are only transferred one way.
The sources from the project directory should be normally auto-transferred on each build (see your VisualGDB Project Properties for file transfer settings).
Sometimes when the target directories are symlinked, gdb reports the path that is different from the one used by VisualGDB and VisualGDB assumes those files are out-of-project files.
Can you identify one particular file that does not get transferred, check its local path, Linux path reported by GDB (see the GDB Session window) and check if your settings are configured to upload the contents of that directory?
Hi,
We have just retested it with the latest Segger J-Link v5.10s and could not find any problem.
We have tested the LEDBlink (BSP) project and tried stepping through the main() function and setting breakpoints – everything worked as expected.
On the first run the J-Link server prompted to update the firmware and we did that. Could you please verify that the problem still exists with 5.10s and after the firmware update?
Hi,
Most likely the connection to your server is slow. Please try switching on the timing analysis mode in the GDB Session window (timer icon) and selecting “All GDB interaction” view. This will show how much time each GDB command takes. If this does not explain the slowness, please let us know which commands are the slowest so that we could advise you further.
Hi,
OK, it looks like VisualGDB is somehow using the obj/local/armeabi-v7a directory for symbols instead of obj/local/arm64-v8a.
Does the arm64-v8a directory exist? What does the VisualGDB Launcher Output say when you try to debug your project?
Hi,
Yes, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.1.4.656.msi
If it does not work, please send us the contents of the %LOCALAPPDATA%\VisualGDB\AndroidBinaryCache folder so that we can try reproducing the problem locally.
Hi,
Strange. The log looks like the gdb included in the Android NDK itself does not support your device. Can you check the VisualGDB Launcher Output for the path of the GDB executable? Perhaps VisualGDB is launching an incorrect version of gdb?
Then you can simply use our ARM toolchain. You can combine our legacy device tutorial with the tutorial you mentioned to enter the correct settings into VisualGDB.
We have also added Teensy boards to our watch list, so if their popularity continues to grow, we will add direct support for some of them.
