search

skeeto / w64devkit

Portable C and C++ Development Kit for x64 (and x86) Windows
The Unlicense
3k stars 211 forks source link

Add gdbserver binary for remote debugging #56

Closed Blzut3 closed 1 year ago

Blzut3 commented 1 year ago

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.

skeeto commented 1 year ago

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.

Blzut3 commented 1 year ago

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.

skeeto commented 1 year ago

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!