From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84892 invoked by alias); 20 Apr 2017 00:11:31 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 84876 invoked by uid 89); 20 Apr 2017 00:11:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=complaint, experiencing, meter, Reading X-HELO: gproxy6-pub.mail.unifiedlayer.com Received: from gproxy6-pub.mail.unifiedlayer.com (HELO gproxy6-pub.mail.unifiedlayer.com) (67.222.39.168) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Thu, 20 Apr 2017 00:11:29 +0000 Received: (qmail 18062 invoked by uid 0); 20 Apr 2017 00:11:29 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 20 Apr 2017 00:11:29 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by CMOut01 with id AQBS1v0082f2jeq01QBVxo; Wed, 19 Apr 2017 18:11:29 -0600 X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=AzvcPWV-tVgA:10 a=20KFwNOVAAAA:8 a=f3F1UzldCgdpG5wRFUIA:9 Received: from 75-166-29-21.hlrn.qwest.net ([75.166.29.21]:51468 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1d0zgz-0004QJ-SQ; Wed, 19 Apr 2017 18:11:25 -0600 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA 2/2] PR cli/19551 - change formatting of "Reading symbols" messages References: <20170413041504.14435-1-tom@tromey.com> <20170413041504.14435-3-tom@tromey.com> <3c04e1c7-7192-07ed-b2ca-ce9ebc0b99a6@redhat.com> Date: Thu, 20 Apr 2017 00:11:00 -0000 In-Reply-To: <3c04e1c7-7192-07ed-b2ca-ce9ebc0b99a6@redhat.com> (Pedro Alves's message of "Tue, 18 Apr 2017 18:42:48 +0100") Message-ID: <87a87c545w.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Exim-ID: 1d0zgz-0004QJ-SQ X-Source-Sender: 75-166-29-21.hlrn.qwest.net (bapiya) [75.166.29.21]:51468 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-SW-Source: 2017-04/txt/msg00574.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: >> It modifies the DWARF reader(s) to update the progress. Pedro> What does GDB show with the reader? Is their output now broken, same, Pedro> etc? Pedro> Sorry, I meant, what does GDB show with the other readers. I didn't update these, so it just prints, e.g.: Reading symbols from outputs/gdb.stabs/weird/weirdx.o I could take a look at the others I suppose. >> Any printing is deferred until the first progress report, so the >> messages no longer clash. Pedro> Can you clarify what printing you're referring to? This bit meant that the "Reading ..." message isn't emitted until the first progress update. This is what makes it so these messages don't clash. Pedro> What happens if gdb emits e.g., complaints while a progress bar Pedro> is half full? You get terrible-looking stuff like: (gdb) file ../gdb Reading symbols from ../gdb [################################### ]unsupported stack op: 'DW_OP_stack_value'...unsupported stack op: 'DW_OP_stack_va[#################################### ]u[#################################### ]u[###################################### ]u[############################################## ]unsupported stack op: 'DW_OP_stack_value'...unsupported stack op: 'DW_OP_stack_value'...unsupported stack op: 'DW_OP_stack_value'...unsupported stack op: 'DW_OP_[############################################################## ]unsupported stack op: 'DW_OP_stack_value'...unsupported stack op: 'DW_OP_stack_va Maybe there's no easy way to improve this :( The issue is that the complaint system just writes to the ui-file, bypassing ui-out entirely. Complaints could be fixed, but this same problem would apply to any possible output during symbol reading. Though FWIW I don't think anybody other than gdb developers enables complaints. Pedro> I noticed that if you clear the screen such that the prompt is not at Pedro> the bottom when gdb reads symbols (e.g., start gdb on itself, Pedro> run to main, do ctrl-l to clear the screen, and do Pedro> "nosharedlibrary / sharedlibrary"), and if symbol reading is quick, then Pedro> the meter appears/disappears very quickly in what looks like an Pedro> odd flash. It looks a tiny bit annoying to me. Though not a deal breaker Pedro> and I'll get used to it for sure. One way around it would be to Pedro> not print the meter unless the operation is taking longer than some Pedro> minimum time, like 1s or some such. I'm wondering if you are seeing the case where the first notification is at howmuch=1.0, causing printing of the progress bar followed by immediately erasing it. I can't see the effect myself, but that's an idea... I changed it to avoid this case specifically. >> + /* Stack of progress meters. */ >> + std::vector m_meters; Pedro> I think it'd be good to have this comment expanded a bit to Pedro> explain why we need a stack, and what happens when we're Pedro> already printing a meter and a new stack level appears. This case also doesn't really work. If a meter is already printing, a new meter will just confuse the output. The current system relies on the way that gdb does symbol reading, where it discovers separate debuginfo before doing any work on the original objfile. Pedro> If implementations can do nothing, shouldn't "nothing" be the Pedro> default implementation? I made the change; but I did it this way originally since the base class looked purely abstract to me. I made all the other changes. I still didn't write the test for the first patch, though, and I'm also experiencing a possible intermittent with the buildbot (not sure, maybe it's my other patch series), so it may be a little while before v2. Tom