Add gdbserver binary for remote debugging #56
Conversation
|
Your patch is perfectly correct, thanks! However, the omission of
gdbserver.exe is deliberate for a couple of reasons:
1. w64devkit is a curation: an opinionated, all-in-one set of tools for a
narrow style of local, "offline" application development, and nothing
more. It doesn't do multilib since it's rarely needed. The non-system
runtime components are static, without a dynamic linking option. It
includes no meta build systems, and makes no presumptions about what
libraries might be useful. I delete/exclude other tools that aren't
relevant to this focus, like Binutils readelf.
2. Remote GDB is a poor experience. The debugger always exits along with
the debuggee, losing all session state. The client debugger has very
limited capabilities. Getting debug/symbol information to the client is a
serious challenge. Unlike local GDB which is great for regular, every day,
all-day-long use, remote GDB is a last resort, when nothing better is
available. (People sometimes use local GDB only as a last resort, but
that's because they don't know any better.)
So by (1) it doesn't fit the focus on local development. Why would one
need a remote debugger while sitting at the target machine? Perhaps a
fitting use case exists, maybe including your situation. Suppose an
application only exhibits a bug while focused and full screened, so it
must be debugged remotely. My mind could be changed on this point,
especially since it only weighs 1.4MB. For (2) I don't want to include a
poor tool unless there's a good reason.
|
|
In regards to point 2, the GDB client actually requests transfer of the symbol information from the remote server automatically for MinGW-w64 at least. (I was a little shocked about how smooth that went myself actually.) Additionally the --multi switch smooths over some of the issues you mention, granted there seems to be a bug in the current version of GDB that causes it to fail an assert if you attach and detach from a running process (say background service). My particular use case is development of a background service which needs to support a large range of Windows releases. As such I have test VMs for each OS release we support (about 14 at this time). So develop on the host machine, test on various VMs which have the absolute minimum amount of deviation from a bare bones OS install (just enough to make the hypervisor happy). This makes your project great over say msys2 since I don't need to further deviate from a base OS install. From my point of view this is all still "local development" since all my dependencies are vendored and all my remote systems are running on a single machine, but I understand if you consider that a stretch. Honestly with modern C++ practices I've spent surprisingly little time in a debugger, but every now and then something goes non-obviously wrong and useful to have something. Sure I could run gdb client inside of the VM, but since each VM is a clean install they're not very comfortable to use. |
|
After some thought, you've convinced me. Merged just in time for GCC 13.1,
which means I'll be cutting a new release in the coming days. Thanks!
|
Found this project while looking for an easy to grab gdbserver executable for Windows. The prebuilt packages didn't have it, but it was a simple change since it was already being built.