- This topic has 6 replies, 2 voices, and was last updated 2 years, 6 months ago by
.
-
Posts
-
Hi,
I’m using VGDB Custom Edition, and so far I have used it successfully to do remote debugging by running gdb itself on the debugged host. However, due to the GDB version there being quite old, I want to connect with a newer version of gdb via gdbserver.
I installed the prebuilt Windows toolchain for Ubuntu, and I can successfully connect and run the program being debugged. I am debugging a Python C++ extension, so while the program being debugged is Python, I don’t care about its symbols or source code. I’m interested in my own C++ library that is being loaded by Python.
However, the problem I have is that I can’t figure out how to map the library (let’s call it libfoo.so) so that the local x86_64-linux-gnu-gdb.exe knows that the remote version of /path/libfoo.so maps to the local version of the same library at C:\path\libfoo.so?
Note that the source mapping is set up correctly, it’s the library mapping that isn’t clear to me.
Thanks
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Sorry, our system still shows the old license expiration date. If you have placed a renewal order, please contact our sales with the order details.
There was an email saying there was some sort of error with the order, error LME763472. The payment went through so I have no idea what the issue is. I forwarded that email to sales@sysprogs.com as well as support@sysprogs.com.
Thanks for renewing your license.
Normally, GDB would automatically search for libraries with symbols in its sysroot directory on the Windows machine (use the “show sysroot” command to find it out). However, you can override this behavior by issuing the set solib-search-path command via the GDB Session window, or adding it to VisualGDB Project Properties -> Additional GDB Commands.
Note that the library on the Windows machine must match the library loaded on the target, otherwise gdb would use incorrect addresses for most symbols, resulting in unpredictable behavior.
Thanks, that worked.
I did find that using gdb on Windows with the so files copied locally ended up being substantially slower than setting up gdb + gdbserver on the same host (so both running on the same host). That is also much faster than using the gdb that comes with that host directly, since it is quite old. But copying a newer gdb to the host and then running it via gdbserver seems to work the best.
- You must be logged in to reply to this topic.