Re: [PATCH v3] gdb: Improve debuginfod progress updates

[Aaron Merey <amerey@redhat.com>]

On Fri, Mar 18, 2022 at 3:23 PM Tom Tromey <tom@tromey.com> wrote:
> Aaron> I'd like to restrict the update messages to a single line so that an
> Aaron> entire message can be overwritten with \r.  Then when many downloads
> Aaron> occur we avoid filling the terminal with "Downloading XY MB separate
> Aaron> debuginfo for libxyz" messages.
>
> Could you show what your proposed output looks like?
> I mean, after everything is downloaded?

After each download, the progress update message is overwritten with
whitespace. So by default there is no lasting indication that a download
occured (this can be changed with 'set debuginfod verbose 2' though).

For example while downloads are in progress a user might see

    (gdb) start
    Temporary breakpoint 1 at 0x40f406: file gdb.c, line 25.
    Starting program: /usr/local/bin/gdb
    \ Downloading separate debug info for /lib64/libc.so.6

where the last line is overwritten with each download's progress message.
When the final download finishes, the message is overwritten with whitespace
and gdb's output continues as if debuginfod wasn't used:

    (gdb) start
    Temporary breakpoint 1 at 0x40f406: file gdb.c, line 25.
    Starting program: /usr/local/bin/gdb
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib64/libthread_db.so.1".

    Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe658) at gdb.c:25
    25  {
    (gdb)

> To me it seems like having a "Downloading..." message per .so is no big deal.
> gdb is often chatty.

I'd like to avoid printing a large number of "Downloading..." messages but
my solution in this patch comes with the added complexity of message
truncation when the terminal isn't wide enough.  Unless there is a desire
among users to limit these messages this way then maybe it's better to
just stick to the cylon-style display you suggested.

> >> Technically MI does have a progress notification approach, see
> >> mi_load_progress.  I don't know if anything MI consumer actually uses
> >> this, though, and so I'm not sure if it makes sense to try to wire this
> >> up to debuginfo downloads.
>
> Aaron> These MI implementations are the easiest way to see progress updates when
> Aaron> using gdb+debuginfod with IDEs, for instance.  Otherwise I think each IDE
> Aaron> would have to learn how to parse and display the mi_load_progress output,
> Aaron> preferably in a way that's consistent with the CLI progress messages.
>
> I am not sure we're talking about the same thing... MI defines a
> progress indication message, but your patch isn't using that.  So I
> wonder if any MI notification is needed at all.

I think I've conflated mi_ui_out with MI itself.  I don't think we'll need
to modify any MI notifications for these progress updates.