public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Aaron Merey <amerey@redhat.com>
To: keiths@redhat.com
Cc: kevinb@redhat.com, gdb-patches@sourceware.org,
	Aaron Merey <amerey@redhat.com>
Subject: Re: [PATCH] Remove download size from debuginfod progress messages
Date: Wed, 23 Mar 2022 14:06:16 -0400	[thread overview]
Message-ID: <20220323180616.29957-1-amerey@redhat.com> (raw)
In-Reply-To: <5ed305d0-3650-a9f9-e128-22f873cd96a0@redhat.com>

Hi Keith,

On Wed, Mar 23, 2022 at 12:02 PM Keith Seitz <keiths@redhat.com> wrote:
> On 3/22/22 17:34, Aaron Merey wrote:
> > Currently debuginfod progress update messages include the size of
> > each download:
> >
> >    Downloading 7.5 MB separate debug info /lib/libxyz.so.0
> >
> > This value originates from the Content-Length HTTP header of the 
> > transfer.  However this header is not guaranteed to be present for 
> > each download.  This can happen when debuginfod servers compress files
> > on-the-fly at the time of transfer.  In this case gdb wrongly prints
> > "-0.00 MB" as the size.
>
> I realize this is an interim patch to address an issue currently
> under development, and I'm okay with that. There are a lot of
> people that use devel versions of gdb to do work. [At least I
> hope I'm not alone!]
>
> However, I would really rather not simply remove all download
> sizes. If we can detect the condition that would print the unhelpful
> "-0.00 MB", then *just* removing the download size for that case (or 
> printing "unknown" or something) would be my preferred path.

I wanted to keep this patch as simple as possible in order to avoid
getting bogged down by details that might be more appropriate for
the patch in-progress that reworks these messages.  But I agree that
we should continue to print sizes if they are available.  I've added
this to the patch below.

Aaron

---
Remove download size from debuginfod progress messages if unavailable

Currently debuginfod progress update messages include the size of
each download:

  Downloading 7.5 MB separate debug info /lib/libxyz.so.0

This value originates from the Content-Length HTTP header of the
transfer.  However this header is not guaranteed to be present for
each download.  This can happen when debuginfod servers compress files
on-the-fly at the time of transfer.  In this case gdb wrongly prints
"-0.00 MB" as the size.

This patch removes download sizes from progress messages when they are
not available.  It also removes usage of the progress bar until
a more thorough reworking of progress updating is implemented. [1]

[1] https://sourceware.org/pipermail/gdb-patches/2022-February/185798.html

---
 gdb/debuginfod-support.c | 44 ++++++++++++++++++++++++----------------
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git a/gdb/debuginfod-support.c b/gdb/debuginfod-support.c
index 3614ff23882..d5d023ff7bb 100644
--- a/gdb/debuginfod-support.c
+++ b/gdb/debuginfod-support.c
@@ -86,12 +86,12 @@ debuginfod_exec_query (const unsigned char *build_id,
 struct user_data
 {
   user_data (const char *desc, const char *fname)
-    : desc (desc), fname (fname)
+    : desc (desc), fname (fname), has_printed (false)
   { }
 
   const char * const desc;
   const char * const fname;
-  gdb::optional<ui_out::progress_meter> meter;
+  bool has_printed;
 };
 
 /* Deleter for a debuginfod_client.  */
@@ -121,24 +121,32 @@ progressfn (debuginfod_client *c, long cur, long total)
       return 1;
     }
 
-  if (total == 0)
-    return 0;
-
-  if (!data->meter.has_value ())
+  if (!data->has_printed)
     {
-      float size_in_mb = 1.0f * total / (1024 * 1024);
-      string_file styled_filename (current_uiout->can_emit_style_escape ());
-      fprintf_styled (&styled_filename,
-		      file_name_style.style (),
-		      "%s",
-		      data->fname);
-      std::string message
-	= string_printf ("Downloading %.2f MB %s %s", size_in_mb, data->desc,
-			 styled_filename.c_str());
-      data->meter.emplace (current_uiout, message, 1);
-    }
+      /* Include the transfer size, if available.  */
+      if (total > 0)
+	{
+	  float size = 1.0f * total / 1024;
+	  const char *unit = "KB";
+
+	  /* If size is greater than 0.01 MB, set unit to MB.  */
+	  if (size > 10.24)
+	    {
+	      size /= 1024;
+	      unit = "MB";
+	    }
+
+	  printf_filtered ("Downloading %.2f %s %s %ps...\n",
+			   size, unit, data->desc,
+			   styled_string (file_name_style.style (),
+					  data->fname));
+	}
+      else
+	printf_filtered ("Downloading %s %ps...\n", data->desc,
+			 styled_string (file_name_style.style (), data->fname));
 
-  data->meter->progress ((double)cur / (double)total);
+      data->has_printed = true;
+    }
 
   return 0;
 }
-- 
2.35.1


  reply	other threads:[~2022-03-23 18:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23  0:34 Aaron Merey
2022-03-23 16:02 ` Keith Seitz
2022-03-23 18:06   ` Aaron Merey [this message]
2022-03-23 18:56     ` Keith Seitz
2022-03-24 15:17     ` Simon Marchi
2022-03-24 19:04       ` Aaron Merey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220323180616.29957-1-amerey@redhat.com \
    --to=amerey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=keiths@redhat.com \
    --cc=kevinb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).