Since commit 7811fa5995 gdb prompts the user for confirmation to download debuginfod, even in --batch mode. Now the manpage doesn't state that gdb won't prompt in batch mode, but still, prompts in batch mode might not be what the user expects and this might've been implemented this way by mistake. As a "workaround" -iex 'set debuginfod enabled o(n/ff)' can be used. See also: https://bugs.kde.org/show_bug.cgi?id=454063 https://sourceware.org/bugzilla/show_bug.cgi?id=27532
If --batch is set then gdb should not wait for user input for any y/n prompt, including the debuginfod first-use notice. The debuginfod notice should default to 'n' when batch mode is on or interactive mode is off. $ cat cmds show interactive-mode br foo run $ gdb --batch -x cmds ps This GDB supports auto-downloading debuginfo from the following URLs: <https://debuginfod.fedoraproject.org/> Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal] Debuginfod has been disabled. To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit. Debugger's interactive mode is auto (currently off). [...] Is batch mode confirmed to be enabled when the prompt causes hanging? Are you able to provide a reproducer for this? Also has drkonqi experienced any issues with gdb's other y/n prompts? The debuginfod prompt is implemented using the same facilities as the prompt that appears when you try to set a breakpoint on a function that gdb cannot find. This prompt also defaults to 'n' when batch mode on or interactive mode off: $ gdb --batch -x cmds ps [...] Function "foo" not defined. Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal] [...] If the debuginfod prompt is hanging then this prompt ought to hang too.
From https://bugs.kde.org/show_bug.cgi?id=454063 it looks like there may have been a misunderstanding that gdb automatically answers prompts in batch mode. Closing as NOTABUG.