[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.

[support]

Hi,

This is starting to look like a gdb bug. Can you reproduce the same behavior outside VisualGDB?

If yes, please try a newer version of gdb and see if running it as root solves the problem.

[Author]

Posts