Forum Replies Created
-
Posts
-
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.
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.
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:
- Go to the CMake Project Settings page and change the ‘cflags’ or ‘preprocessor macros’ field (e.g. add a new dummy macro).
- 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.
- 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.
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.
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?
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.
Hi,
Please try configuring it as follows:
- In GDB Start mode select “start new instance”
- In “debugged program” select “/bin/sh”
- Set program arguments to <script file> <arguments>
- 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.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.
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?
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.
If you want to add a Windows configuration to an existing VisualGDB project, you can use the VS configuration manager to add it and then switch the configuration type from NMake to Application.
Unless you are using the new MSBuild backend, VisualGDB configurations are normal NMake configurations (from VS point of view) that simply call VisualGDB.exe to do the actual build. If you change them back to normal Application configurations, VisualGDB won’t engage and you will be able to build an debug them normally.
Hi,
Sorry about that. VisualGDB 5.2 actually does most of the preparation steps in background threads, so it should not show any dialogs during session startup. Please try updating to the final v5.2.
If it does not help, please let us know which exact dialog causes this because we are using a similar trick for most of them to avoid the problem you described.
