$ gdbserver :1234 C:/Users/tester/Documents/NetBeansProjects/Arguments_1/dist/Debug/MinGW-Windows/arguments_1.exe Process C:/Users/tester/Documents/NetBeansProjects/Arguments_1/dist/Debug/MinGW-Windows/arguments_1.exe created; pid = 864 Listening on port 1234 Remote debugging from host 127.0.0.1 pid = 864 $ gdb --interpreter mi =thread-group-added,id="i1" ~"GNU gdb (GDB) 7.6.1\n" ~"Copyright (C) 2013 Free Software Foundation, Inc.\n" ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\n" ~"This GDB was configured as \"mingw32\".\nFor bug reporting instructions, please see:\n" ~"<http://www.gnu.org/software/gdb/bugs/>.\n" (gdb) target remote :1234 &"target remote :1234\n" ~"Remote debugging using :1234\n" =thread-group-started,id="i1",pid="42000" =thread-created,id="1",group-id="i1" ~"0x77a60fac in ?? ()\n" *stopped,frame={addr="0x77a60fac",func="??",args=[]},thread-id="1",stopped-threads="all" ^done (gdb) pid = 42000
"42000" is a magic internal PID number that GDB uses whenever it can't figure out the target's pid. On GNU/Linux, GDBserver activates the multi-process extensions (target_supports_multi_process) and thus GDB knows the real inferior's PID. The trouble is that gdbserver's Windows backend doesn't support multi-process, and so gdbserver doesn't tell GDB the real PID of the process. Maybe we could activate the extensions even if the target backend can't debug more than one process at a time. We'd need to make server.c refuse vRun / vAttach if already debugging a process, on !target_supports_multi_process targets, but it would probably works. (tbc, not going to do it myself)