From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id ACE773858D3C for ; Thu, 24 Mar 2022 15:17:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ACE773858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.95] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 467451F0BB; Thu, 24 Mar 2022 11:17:44 -0400 (EDT) Message-ID: Date: Thu, 24 Mar 2022 11:17:43 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH] Remove download size from debuginfod progress messages Content-Language: tl To: Aaron Merey , keiths@redhat.com Cc: gdb-patches@sourceware.org References: <5ed305d0-3650-a9f9-e128-22f873cd96a0@redhat.com> <20220323180616.29957-1-amerey@redhat.com> From: Simon Marchi In-Reply-To: <20220323180616.29957-1-amerey@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3639.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2022 15:17:46 -0000 On 2022-03-23 14:06, Aaron Merey via Gdb-patches wrote: > Hi Keith, > > On Wed, Mar 23, 2022 at 12:02 PM Keith Seitz 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 I'm fine with an interim patch, but I'd really like to see the progress bar back, I enjoy it :)! I haven't been involved in those dicussions so I don't know what the plan is. But typically progress bars have an "undefined total" mode where you can still tell that the operation is progressing (bytes are being received), you just don't what percentage of the total. But really, is it a problem for GDB master to print "~0.00 MB", until the "real" fix is merged? It's not like it's causing a crash or anything like that? Or is it something you want to push to the GDB 12 branch? The patch LGTM in any case, if that's the route you want to take. Simon