If you use Visual Studio on Windows, you have one nice option for multi-process debugging: https://marketplace.visualstudio.com/items?itemName=vsdbgpla... - auto-attach the debugger to child processes as they are invoked. I've also found this good in the past for debugging some kinds of client/server setup by having a little wrapper program that runs the combination of clients and servers required on your local PC.
All the processes end up being debugging simultaneously in the same instance of the debugger, which I've found to make light work of certain types of annoying bug. You might need a mode where the timeouts are disabled though!
Re:Don't Look Down on Print Debugging
by kazinator on Saturday November 23, 2024 @10:19AM
(#42221350)
In the embedded world, you use remote debugging (like gdbserver on the target and gdb on a development machine). There are issues like some third party pieces being debugged that are not part of your application, and not built in a way that plays along with your debugging environment. Those pieces may be started not simply by shell scripts, but C code, which hard codes some of their arguments and whatnot. You need networking for remote debugging, but the problem you're debugging might occur before networking is up on the target.
It's particularly annoying on projects that are set up without considering proper debuggers, because often it's impossible or difficult to use them, e.g. if your program is started via a complicated bash script or makefile rather than directly.