Forum Replies Created
-
Posts
-
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.
Hi,
Normally VisualGDB should handle this automatically. Please let us know an example error message you get and we will suggest how to resolve this.
Hi,
This looks like a bug. Could you try removing the %LOCALAPPDATA%\VisualGDB\RemoteSourceCache\192.168.1.27 directory and reloading the directories? If the problem is reproduced, could you send us your .vgdbsettings file and the .vxcproj file so that we could try reproducing it on our side?
Hi,
This could be an indication of a bug in gdb/gdbserver. Could you double-check via the gdb command log that the “set follow-fork-mode child” command is accepted correctly and not overridden later?
Can you also reproduce the problem with a regular command-line gdb?
