*** Bug 29581 has been marked as a duplicate of this bug. ***

This seems to work:
...
diff --git a/gdb/debuginfod-support.c b/gdb/debuginfod-support.c
index 5f04a2b38ca..69dad2b9b86 100644
--- a/gdb/debuginfod-support.c
+++ b/gdb/debuginfod-support.c
@@ -119,6 +119,12 @@ progressfn (debuginfod_client *c, long cur, long total)
       gdb_printf ("Cancelling download of %s %ps...\n",
                  data->desc,
                  styled_string (file_name_style.style (), data->fname));
+      int resp = nquery (_("Cancel further downloading for this session? "));

+      if (resp)
+       {
+         gdb_printf (_("Debuginfod has been disabled.\n"));
+         debuginfod_enabled = debuginfod_off;
+       }
       return 1;
     }
 
...

Example session:
...
$ gcc ~/hello.c -g
$ rm -Rf ~/.cache/debuginfod_client/
$ gdb -q -iex "set debuginfod enabled on" a.out -ex start
Reading symbols from a.out...
Temporary breakpoint 1 at 0x40113a: file /home/vries/hello.c, line 6.
Starting program: /data/vries/gdb_versions/devel/a.out 
Downloading separate debug info for /lib64/ld-linux-x86-64.so.2...
^CCancelling download of separate debug info for /lib64/ld-linux-x86-64.so.2...
Cancel further downloading for this session? (y or [n]) y
Debuginfod has been disabled.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at /home/vries/hello.c:6
6         printf ("hello\n");
(gdb) info shared
From                To                  Syms Read   Shared Object Library
0x00007ffff7fc90a0  0x00007ffff7ff0025  Yes (*)     /lib64/ld-linux-x86-64.so.2
0x00007ffff7dd6700  0x00007ffff7f3bd8d  Yes (*)     /lib64/libc.so.6
(*): Shared library is missing debugging information.
(gdb) 
...

I like it Tom, thanks for it.

(In reply to Tom de Vries from comment #2)
> diff --git a/gdb/debuginfod-support.c b/gdb/debuginfod-support.c
> index 5f04a2b38ca..69dad2b9b86 100644
> --- a/gdb/debuginfod-support.c
> +++ b/gdb/debuginfod-support.c
> @@ -119,6 +119,12 @@ progressfn (debuginfod_client *c, long cur, long total)
>        gdb_printf ("Cancelling download of %s %ps...\n",
>                   data->desc,
>                   styled_string (file_name_style.style (), data->fname));
> +      int resp = nquery (_("Cancel further downloading for this session?
> "));
> 
> +      if (resp)
> +       {
> +         gdb_printf (_("Debuginfod has been disabled.\n"));
> +         debuginfod_enabled = debuginfod_off;
> +       }
>        return 1;
>      }

As long as debuginfod remains enabled gdb will query the user every time they cancel a download. I think it would be preferable for gdb to remember when the user answered "n" so that individual downloads can be cancelled without having to answer the query each time.

Maybe we should also add a gdb command such as 'set debuginfod cancel-all on/off' so that the behavior of ctrl-c during downloads can be set without having to answer the query every session. 'on' could mean ctrl-c disables debuginfod while 'off' only cancels the current download.

(In reply to Aaron Merey from comment #5)
> (In reply to Tom de Vries from comment #2)
> > diff --git a/gdb/debuginfod-support.c b/gdb/debuginfod-support.c
> > index 5f04a2b38ca..69dad2b9b86 100644
> > --- a/gdb/debuginfod-support.c
> > +++ b/gdb/debuginfod-support.c
> > @@ -119,6 +119,12 @@ progressfn (debuginfod_client *c, long cur, long total)
> >        gdb_printf ("Cancelling download of %s %ps...\n",
> >                   data->desc,
> >                   styled_string (file_name_style.style (), data->fname));
> > +      int resp = nquery (_("Cancel further downloading for this session?
> > "));
> > 
> > +      if (resp)
> > +       {
> > +         gdb_printf (_("Debuginfod has been disabled.\n"));
> > +         debuginfod_enabled = debuginfod_off;
> > +       }
> >        return 1;
> >      }
> 
> As long as debuginfod remains enabled gdb will query the user every time
> they cancel a download. I think it would be preferable for gdb to remember
> when the user answered "n" so that individual downloads can be cancelled
> without having to answer the query each time.
> 
> Maybe we should also add a gdb command such as 'set debuginfod cancel-all
> on/off' so that the behavior of ctrl-c during downloads can be set without
> having to answer the query every session. 'on' could mean ctrl-c disables
> debuginfod while 'off' only cancels the current download.

Good points.

I've come up with "set debuginfod cancel one/all/ask" to address these.

Created attachment 14367 [details]
tentative patch

(In reply to Tom de Vries from comment #7)
> Created attachment 14367 [details]
> tentative patch

Thanks for the patch, I think this works nicely. I just have a couple suggestions regarding some of the wording. 

> +      if (debuginfod_cancel == debuginfod_ask)
> +	{
> +	  int resp = nquery (_("Cancel further downloading for this session? "));
> +	  if (resp)
> +	    debuginfod_cancel = debuginfod_all;
> +	  else
> +	    debuginfod_cancel = debuginfod_one;
> +	}
> +      if (debuginfod_cancel == debuginfod_all)
> +	{
> +	  gdb_printf (_("Debuginfod has been disabled.\n"));

Here it could be useful to include instructions for how to re-enable debuginfod. Something like: 
"Debuginfod has been disabled. To re-enable use the 'set debuginfod enabled on' command."

> +  add_setshow_enum_cmd ("cancel", class_run, debuginfod_cancel_enum,
> +			_("Set cancellation mode for debuginfod."),
> +			_("Show cancellation mode for debuginfod."),
> +			_("\
> +When set to one, ^C cancels a single download.\n\
> +When set to all, ^C cancels all further downloads.\n\
> +When set to ask, ^C asks what to do."),

To be extra clear about what the cancellation mode is I'd add the following line:

The cancellation mode controls the behavior of ^C while a file is downloading from debuginfod.\n\
When set to one, ^C cancels a single download.\n\
...

https://sourceware.org/pipermail/gdb-patches/2022-September/192188.html

(In reply to Tom de Vries from comment #9)
> https://sourceware.org/pipermail/gdb-patches/2022-September/192188.html

I wonder why this patch was never pushed.

(In reply to Hannes Domani from comment #10)
> (In reply to Tom de Vries from comment #9)
> > https://sourceware.org/pipermail/gdb-patches/2022-September/192188.html
> 
> I wonder why this patch was never pushed.

I've updated this patch and reposted it to gdb-patches

https://sourceware.org/pipermail/gdb-patches/2024-February/206331.html