I have been tasked with setting up a development environment for an embedded platform. So far, I have set up a remote build host in NetBeans, which copies all of the source files to the target device, compiles them natively with the GNU toolchain on the device (g++, ld, etc.), and then runs the compiled binary and forwards stdout to the development machine that NetBeans is running on.
What I don't understand is: How does the binary on the build machine know where and when to start/stop if the breakpoints exist only in NetBeans? The build host only required ssh access and a compiling/linking toolchain, but somehow seems to communicate with NetBeans for debugging. A colleague of mine suggested it uses gdbserver, but I have not found any documentation on the NetBeans website about this package, and it is not installed on the build host (at least not from apt). How is NetBeans doing this?
GUI IDE's which use (or can be configured to use) a distinct command-line toolchain for compilation and debug typically do this by running each required toolchain program as a subprocess and interacting with it through standard streams. Essentially, the IDE would use gcc or gdb with the same textual interface used when running it in a terminal window. The IDE uses its knowledge of lines in the source file to configure breakpoints in gdb much as you would while running it by hand.
In your case, the IDE is configured to use a "remote host" for all of this, so instead of being invoked locally, the toolchain is controlled through as ssh session to the remote machine where both building and running occur.
Because the gdb debugger and the target program are running on the same computer, no gdbserver is required.
In the cases where gdb is too large for the target system, gdbserver is a small program which often gets cross-compiled for the target and loaded onto it. This serves as a compact little delegate which talks to the main gdb program running on a build machine via a serial or network connection and performs the raw interaction with processor, memory, and running program on behalf of gdb.
Another possibility is that the gdbserver role is held by a helper program running on the same machine as gdb which instead commands something like a JTAG debug adapter to interact with the target hardware at a lower level. In this case however, the helper program implementing the gdbserver protocol is not usually called "gdbserver" but instead has an implementation specific name, for example openocd.