[support]

Hi,

First of all, we have to apologize that due to many customizations of the Android kernel compared to the regular Linux kernel, VisualKernel we do not officially support it. That said, if you encounter any problems, please let us know and we will do our best to suggest a workaround, but we cannot guarantee that it will work.

Regarding the differences between VisualGDB and VisualKernel: VisualGDB allows developing user-mode applications, Android tools and C/C++ libraries used in Android apps; the kernel-mode development is the case for VisualKernel.

Our arm cross-compiler only works for barebone embedded devices and does not support ARM64.

IntelliSense is designed to run in a separate background process and automatically restart in case of crashes. If you get the “IntelliSense crashed” message with the dump file, we encourage you to share the dump file with us via the support form. As our IntelliSense is using the 3rd-party Clang compiler, it does sometimes crash due to Clang bugs, but we normally fix those issues very quickly.

As the normal Linux kernel cannot be reliably build on Windows, VisualKernel does not support it. You can try configure VisualGDB to build it via the “Import Linux Project” option in the Linux wizard, but it will not recognize it as a Linux Kernel and won’t do any automatic setup steps.

The problem with building the Linux kernel on Windows is that the Makefiles actually rely on building various auxiliary tools that rely on Linux-specific API and won’t work on Windows. Hence VisualKernel always requires a Linux machine to build the kernel.

[support]

Hi,

Looks like your gdb log does not contain the “set follow-fork-mode” line.

Please double-check that you are setting it correctly.

[support]

Hi,

The restriction for the amount of simultaneous breakpoints in FLASH is a limitation of the microcontroller. However it should clearly show a message like “too many hardware breakpoints” and not hang.

Could you please try stopping the program at a breakpoint, adding more breakpoints to exceed the limit and pressing F5 to continue? Does it hang as well? Do you get the same behavior on all devices?

[support]

Hi,

Sorry for the confusion. The ‘VisualGDB’ platform corresponds to the new MSBuild backend introduced in v5.2. The regular ‘Win32’ platform corresponds to the old-style projects that use GNU Make or CMake.

Since v5.2, we recommend using the new MSBuild backend (‘VisualGDB’ platform) for all new projects, so normally the old ‘Win32’ platform should not appear for the VisualGDB projects. If it does despite selecting MSBuild, please let us know the steps to reproduce it and we will fix it.

[support]

Hi,

The “$(shell)” expansion is specific to GNU Make. I.e. if you just put it into a .bat file, Windows won’t expand it, however if you put it into a Makefile as shown in the previous post and run make.exe from your toolchain, it should get substituted properly.

[support]

Hi,

Sorry for the delayed reply. We have done a research on this and it looks like gdbserver from gdb 7.10+ supports the ‘set follow-fork-mode’ properly.

Please download the sources of the latest gdb (we tested 7.12), build them on your Linux machine and replace your normal gdbserver executable with the one built from the latest sources. This should resolve the problem automatically.

[support]

Hi,

Thanks for the project file. Unfortunately we still could not reproduce this as it seems to be caused by the layout of include directories on your remote machine.

Please try the steps below to diagnose this further:

1. Go to the CMake Project Settings page and change the ‘cflags’ or ‘preprocessor macros’ field (e.g. add a new dummy macro).
2. Press “Apply” to trigger retesting of the toolchain and reloading of directories. This should do a clean rebuild of the previously deleted directory under RemoteSourceCache.
3. Go to the IntelliSense Settings page and try reloading the directories. If the problem persists, please send us the updated project/.vgdbsettings file and a snapshot of the RemoteSourceCache\192.168.1.27 directory. This should help us reproduce this and understand why the problem happens.

[support]

Hi,

Sorry about that, it’s a known limitation. The easiest workaround would be to create a normal ‘application’ project/configuration and then replace the “add_executable” statement in CMakeLists.txt with “add_library”. If this does not work, let us know and we will add better GUI support.

[support]

Hi,

Are you using the latest version 5.2? We had a similar bug in v5.1 and it got fixed in v5.2.

If yes, could you please attach your gdb session log so that we could check what is going on?

[support]

Hi,

Thank for reporting this. We are aware of it and will resolve it in the final release of the BSP. Currently is should be safe to ignore this.

[support]

Hi,

Please try configuring it as follows:

1. In GDB Start mode select “start new instance”
2. In “debugged program” select “/bin/sh”
3. Set program arguments to <script file> <arguments>
4. Add the following 2 commands to pre-debug commands:

file <your executable launched by the script>
set follow-fork mode child

This should force gdb to start debugging sh with your script and then automatically switch to debugging your program once it gets started by the script.
This will not work with gdbserver though and will require launching gdb on the target machine directly.

[support]

Yes, we got the hardware and will most likely release a BSP in the next few weeks.

[support]

Hi,

Please give it a try. We have received a lot of feedback about slow debug startup in v5.1 and significantly optimized it in v5.2.

[support]

Yes, this could be related to the extended remote mode. Are you using a cross-toolchain?If yes, could you try opening the Quick Debug window, selecting the normal gdb on the remote machine (not cross-gdb mode) and checking if set follow-fork works there?

[support]

Hi,

Are you using the latest VisualGDB 5.2? This mechanism was improved in a few recent releases.

[Author]

Posts