March 11, 2016 at 12:45 #7752
I am debugging a program running on a Linux server. I am running VisualGDB in Visual Studio on my Windows PC.
Debugging the C++ program is extremely slow. It takes 5 seconds to single-step from one line to the next.
My PC is otherwise quite fast and the connection to the Linux server is very fast – so what could be the reason?March 11, 2016 at 18:16 #7753
Most likely the connection to your server is slow. Please try switching on the timing analysis mode in the GDB Session window (timer icon) and selecting “All GDB interaction” view. This will show how much time each GDB command takes. If this does not explain the slowness, please let us know which commands are the slowest so that we could advise you further.March 14, 2016 at 09:05 #7774
I found out that the extreme slowness arises when I view the “Autos” and “Locals” windows in the GDB Session area.
If I just view the “GDB Session” view then it is relatively fast. But if I view the autos or locals, it is 10-20 times slower. So apparently the viewing of local variables really slows it down to become unusable.
Is there a way to speed viewing of local variables up?
It seems that for each variable, it is executing a command like this:
162 ms: -var-info-path-expression “var127″
So if there are many variables, it adds up…March 15, 2016 at 06:10 #7776
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.September 11, 2017 at 07:10 #12345
I have the same problem as the OP.
I build and run everything on a Linux VM, and then Remote Attach to it through VisualGDB. So the latencies are a minimum, but watching a variable is still so slow that it’s becoming useless.
I can easily setup a gdbserver on the Linux VM, but could you explain what is meant by “cross-gdb”? Exactly how would that setup look like? Do you mean to replace the builtin GDB from VisualGDB, or?
AsgerSeptember 11, 2017 at 18:47 #12354
A cross-gdb is a Windows build of gdb targeting your Linux machine. You can normally obtain it by downloading the sources for the same version of gdb as your Linux VM uses (applying Debian patches if relevant) and building it on Windows from a MinGW shell (you would need to specify target and the target options to 100% match the configuration of your Linux gdb).
As a result you will get a gdb.exe that can run directly on Windows and communicate to the remote target via the gdbserver protocol.
You can also try using one of the gdb binaries from this archive, however they may end up being incompatible with your target due to incompatible flags.September 12, 2017 at 10:09 #12356
thank you for clarifying.
However, don’t I need to somehow redirect VisualGDB to use this new gdb.exe? Perhaps you have a tutorial on this (like you have for so many other things, which is great BTW.).
AsgerSeptember 13, 2017 at 06:22 #12360
No problem. The easiest way to do this would be to use Debug->Quick Debug command (requires Custom edition) and select:
- Target: Linux system
- Use a cross-compiler on the Windows machine
Then VisualGDB will let you choose a toolchain containing the gdb. Simply click “locate a cross-toolchain by finding its gdb.exe” and point it to your gdb executable.
If you use regular VisualGDB projects to build your project, we can help you configure them as well. Do you use the regular “start a new instance” setting?September 13, 2017 at 11:29 #12364
I only have the regular version of VisualGDB.
I don’t use it for building, but solely as a remote debugger. So in VS: Debug->Attach To Process->VisualGDB
How would I use the custom gdb.exe in such as case?
AsgerSeptember 13, 2017 at 17:12 #12368
By regular, do you mean the Linux edition? If yes, please create a normal cross-compilation project as shown here and modify its debug settings so that it will debug your application instead of its build output (that should be ignored). Note that you would need to manually copy the built ELF file from the Linux machine to the Windows machine so that the Windows gdb can load it.
You must be logged in to reply to this topic.