Forum Replies Created
-
Posts
-
Hi,
Yes, you can try debugging with a cross-gdb that will run on the Windows machine and connect to your Linux one via gdbserver. Then the symbol handling will be done on the Windows side and the Windows/Linux latencies won’t affect those commands.
Hi,
It looks like an obvious bug in our device definitions, so there is no action needed on your side, we’ll simply release a BSP update fixing this within the next 24 hours.
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.
