From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4680D3858C51 for ; Tue, 22 Mar 2022 00:27:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4680D3858C51 Received: from mail-yb1-f198.google.com (mail-yb1-f198.google.com [209.85.219.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-580-rIpFByn_O--0GVSE7ZHPug-1; Mon, 21 Mar 2022 20:27:33 -0400 X-MC-Unique: rIpFByn_O--0GVSE7ZHPug-1 Received: by mail-yb1-f198.google.com with SMTP id b16-20020a253410000000b00633b9e71eecso7983729yba.14 for ; Mon, 21 Mar 2022 17:27:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kxqS/FBTsjWUUQcOwkPXngZ3k0w1X6ymMZwXlW/oOoo=; b=B5nVm3pYGFmoZs3TszqUGzokIWxiG+wOwxm1h8H/wJRZ6LarrMUsAIYRxR2WqO5Ffd /mYMn6d9U0whssci1ysdNf49mff+wvl/s5HBbF4yhL/tLcRIfWFPffkkKnLge87mVdmv 20+uN1Pz8d745w2rBpuw93nE0qrGat5AbMYmrzFAQA1MrILc21ndf4l2DF1vBzG9cZko MFLuhRr9JovcCn+l/vVbkCtLmg/zXK7jppZ1Zo27iHp3Luz/tYtMmRGjGsE+s6c/pXY2 PKtJTyfZfvdVU6mxV3ZjXaGMQ1skSPyd3MxHb6XVxe5WGsLTaHou/WUgDtdHtFw2VOLl hrLw== X-Gm-Message-State: AOAM531flED6yl4jGqZDczsSen+0qXBYywBIKh3k8iLY/hRg+pt+uGpQ Sr1fKKzuzOlXrmNLU/1D8vDZ0ozCn+rrO4htTq9oQ035Kx+/EqDRTiyFszHi9vcMXbXMTyYeMb0 hPFqPpd4FxkGV8uzQMIDBhbVx5b6UETyEslIH X-Received: by 2002:a81:c54:0:b0:2e6:17c4:c7f3 with SMTP id 81-20020a810c54000000b002e617c4c7f3mr11470176ywm.129.1647908853131; Mon, 21 Mar 2022 17:27:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJylVYIYKobAXO6dZx+cUI/JRQ0CFQzBGCwdiN9e716ysF0cSJ1INfQ9iTOxFbekDBhspE2pO5iWUMhq6a/G5yM= X-Received: by 2002:a81:c54:0:b0:2e6:17c4:c7f3 with SMTP id 81-20020a810c54000000b002e617c4c7f3mr11470163ywm.129.1647908852882; Mon, 21 Mar 2022 17:27:32 -0700 (PDT) MIME-Version: 1.0 References: <20220126005817.56356-1-amerey@redhat.com> <20220209022548.343785-1-amerey@redhat.com> <875yotshxd.fsf@tromey.com> <87y217gj54.fsf@tromey.com> In-Reply-To: <87y217gj54.fsf@tromey.com> From: Aaron Merey Date: Mon, 21 Mar 2022 20:27:22 -0400 Message-ID: Subject: Re: [PATCH v3] gdb: Improve debuginfod progress updates To: Tom Tromey Cc: Aaron Merey via Gdb-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: Tue, 22 Mar 2022 00:27:36 -0000 On Fri, Mar 18, 2022 at 3:23 PM Tom Tromey 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.