[support]

Hi,

The J-Link uses its own implementation of semihosting that can be enabled with the “monitor semihosting enable” command as described here.

If you want to use the VisualGDB implementation of it, please try using OpenOCD instead.

[support]

Hi,

Good to know it worked. Let us know if you run into any problems.

[support]

Hi,

Sure, we could add a command like that. Do you mean the equivalent of the “Program and Start Without Debugging” command in the Debug menu?

[support]

Good to know it worked. Let us know if you encounter further problems.

[support]

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.

[support]

OK, the update is out. Please update your BSP via Tools->Embedded Tools Manager.

[support]

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.

[support]

Yes, simply use the File->Export VisualGDB Project Template command. We will publish a tutorial on that soon.

[support]

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.

[support]

Hi,

OK, strange. According to your log file, the breakpoint gets set correctly. Please try modifying your code as follows:

1. Add a function “void test() {asm(“nop”);}
2. Change the stringFromJNI() function to return the address of the test() function instead of the counter: sprintf(sz, “test=0x%x”, &test);
3. 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?

[support]

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

[support]

Hi,

OK, we have added this to the v5.2 feature list.

[support]

Hi,

Please find your answers below:

1. We do allow using a personal license on one additional computer (e.g. a laptop).
2. The license is perpetual, however the free updates and support will only work for 1 year.
3. 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.

[support]

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?

[support]

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?

[Author]

Posts