- This topic has 9 replies, 3 voices, and was last updated 7 years, 2 months ago by
.
-
Posts
-
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?
Hi,
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.
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″
^done,path_expr=”error_id”So if there are many variables, it adds up…
Hi,
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.
Hi,
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?
Thanks,
Asger
Hi,
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.
Hi Support,
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.).
Regards,
Asger
Hi,
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?
Hi,
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?
Thanks,
Asger
Hi,
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.