Here's a life changing tip to avoid this kind of issues with GDB: use the extended-remote mode.

Open two terminals (e.g. in tmux), and in the first one run the GDB server.

    $ gdbserver --multi :5555

In the second terminal, open GDB client or your favorite GDB frontend (this can be used with Emacs or Eclipse or whatever):

    $ gdb -tui
    (gdb) target extended-remote :5555
    (gdb) set remote exec-file /remote/path/to/executable # this exe may be stripped
    (gdb) file /path/to/executable_with_debug_syms
    (gdb) set args --cmdline_for_my_app
    (gdb) run
    ... go ahead with your usual debugging

You should save this gdb script to a file and pass it to gdb (`gdb -x myfile.gdb`) or put it in `$PWD/.gdbinit` (put `add-auto-load-safe-path` in `$HOME/.gdbinit`).

(note: if your gdbserver and client are on the same machine, the file path can be the same for "file" and "set remote exec-file")

The program under debug is forked by the gdbserver process in your 1st terminal window. This should avoid the issue in the article by not multiplexing your debuggee process input/output with the GDB frontend's (in the 2nd terminal window).

Compared to normal remote debugging mode, the extended remote mode can restart the process without restarting the debugger and generally has all the features you have in "normal" local debugging. The downside is that it requires an operating system that can run gdbserver, you can't use extended-remote mode for debugging on bare metal firmware, kernel images etc.

I use the extended-remote mode for all debugging because I don't like the process output being interleaved with messages and prompts from GDB. This interleaving is also pretty buggy, especially with certain frontends (like cgdb). Terminal escaping is often broken, and especially if the debuggee process is something with a terminal UI (ncurses etc), it's just not gonna work.

Naturally, being remote debugging, you get the ability to debug across operating systems and CPU architectures. I have my dev tools on an x86 Linux box, but I regularly debug and test on Windows and ARM devices over the network or serial line. Added bonus: you can upload stripped executables on the target device, and the debug symbols can be on your dev box only. This is a huge advantage if you're working on an embedded platform with a slow connection (UART serial ports etc). You may need to configure search paths (set solib-search-path etc) to get the debug syms for any shared libs etc.

One thing that does not work: GEF and other advanced GDB scripts. Some of their features rely on being a local process and having access to /proc filesystem for that process.

Here's the manual pages for remote debugging: https://sourceware.org/gdb/onlinedocs/gdb/Remote-Debugging.h...