Thanks. Does the patch below give good results?

Yes but gud-filter-defer-flag seems to be a global so if you have several gdb sessions going they all get confused while waiting for the y-or-no-p.

To test I did:

1. M-x gdb, start debugging process A, stop at breakpoint

2. M-x gdb, attach to process B, waiting at y-or-n-p

3. Type "step" in A's gdb window

4. Answer "y" to the y-or-n-p for B

This sent output from A's gdb to B's gdb buffer!

It seems gud-filter-defer-flag and gud-filter-pending-text should be buffer-local (or process properties?) to avoid this.

But I don't know this code at all so...

That said, your patch is definitely a big improvement and the above error case is a bit contrived :)

diff --git a/lisp/progmodes/gdb-mi.el b/lisp/progmodes/gdb-mi.el
index 74dff32..ebaff4a2 100644
--- a/lisp/progmodes/gdb-mi.el
+++ b/lisp/progmodes/gdb-mi.el
@@ -1108,7 +1108,9 @@ gdb-init-1
;; trigger questions about debuginfod queries.
(if (eq gdb-debuginfod-enable 'ask)
(setq gdb-debuginfod-enable
- (y-or-n-p "Enable querying debuginfod servers for this session?")))
+ (let ((gud-filter-defer-flag t))
+ (y-or-n-p
+ "Enable querying debuginfod servers for this session?"))))
(gdb-input (format "-gdb-set debuginfod enabled %s"
(if gdb-debuginfod-enable "on" "off"))
'gdb-debuginfod-message)