>
> 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)
>