This is a classic problem that people have with gdb. It’s so common that you’d think it would have a handy name!
There are a few solutions to the problem, some time-tested and some relatively more experimental.
If the program to debug (in gdb lingo, "the inferior") is long-running -- for example, a GUI or a server of some kind -- then the simplest way is to just run the script, wait for the inferior to start, and then attach to it. You can attach using the PID, either with gdb -p PID or using attach PID at the gdb prompt.
If the program is short-lived, then another classic approach is to add a call to sleep early in the program's startup; say as the first line of main. Then, continue with the attach plan.
Those are the classic ways. But now let’s talk about the more fun stuff.
gdb has a multi-inferior mode, where it can debug multiple processes at once. This mode, IME, is still a bit fragile, but I’ve had some success with it.
First you put gdb into the correct mode:
set detach-on-fork off
set non-stop off
set pagination off
(If you have an older gdb you will also need set target-async on).
Now you can debug the shell, something like:
$ gdb --args /bin/sh /path/to/my/script
(gdb) [… set the mode as above …]
(gdb) break some_function_in_my_inferior
Now run should start the script, and automatically attach gdb to each child process that’s created; eventually stopping at the breakpoint.
There’s still one more way. A long time ago, there was a kernel patch to add “global breakpoints”, plus a gdb patch to work with this feature. As far as I know, none of this was ever merged. But, I wrote a variant in my gdb helpers project.
There is a new command there called preattach. What it does is use SystemTap to watch for an exec of a specified program; then it pauses this program while gdb attaches to it.